模厂朋友自建Benchmark：公开榜单被刷成废纸，他写了份指南

几周前，我跟一位模型厂的朋友碰了面。他手里有个自己用的Benchmark，题目挑得极偏，他说拿这个去摸新模型的底，体感能准不少。

眼下国内模型把各种榜单都刷飞了，这么个Benchmark，价值自然不小。

我就问他，有没有兴趣把Bench开源出去。他回了一句：「任何一个公开的Benchmark都将是被模型刷榜的废纸，这玩意只适合自己琢磨自己的。」

公开是不想公开，不过他打算把自己的经验和方法拿出来，教更多人怎么用现成的工具搭一套属于自己的Benchmark，于是写了篇Bench指南给大家。

下面是他写的。

我为什么要建自己的Benchmark？原因有三点：

1.让我放心做喷子。年初我喷GLM瘸腿，现在喷DeepSeek的Coding能力不足，这个个人Benchmark都给了我很大的底气。

有些网民是真可怕，说GLM不好、说DS不行，搞得像犯了天条。

2.想看看模型什么时候能替掉我大部分工作

3.给我自己建个知识库

好的Benchmark，都是从真实场景里长出来的。

跟大模型打交道的过程中，很多人应该都碰上过下面这些情况：

把Prompt稍微动了一下，感觉效果好像变好了，可又拿不准是不是心理作用；

换上一个号称「Ultra、SOTA、国产之光」的新模型，偏偏在某些日常任务上效果开始雪崩；

跑了几个经典场景，看着还行，真上线或者批量用起来，各种莫名其妙的错误一个接一个。

这些问题，传统NLP时代就一直存在。Benchmark的意义也在这里：

要完整验证一个场景下模型能不能Work，光挑几个试试就下结论是不行的，评测得尽量还原某个场景的实际状态。

建Benchmark，一是为了有立场，二是为了定义立场。只显示分数没什么意义，人需要归因，得去看数据的分布，才能判断下一步是改Prompt、换模型，还是补流程。

所以好的Benchmark一定是从真实场景里长出来的。以前在工业场景下，不少Benchmark是先拿到客户那边的具体case，再靠人工泛化。

现在有了大模型，很多Benchmark的做法是去公开数据集里抄题目，或者让模型照着一个case批量合成几百个。

不过在我看来，Benchmark要是不贴着真实场景走，压根就站不住脚。

个人向的Benchmark，理应是自己碰上的问题一点点攒出来的。至少第一版得从实际遭遇里总结，不能凭空捏造。

真想批量造case，那就拿聪明的模型去考笨的模型。

那Benchmark和case到底该怎么设计？

我的Benchmark里有一部分常识题，一直活到了GPT-5时代。GPT-4那个Aha时刻到来时，不少传统NLP的复杂case照样能把模型难住。

头一件事是盯紧数据分布。

我的Benchmark之所以能活得久，跟我给它划的应用场景够宽有关。

我本科学的物理和计算机，另外还辅修了文学。

于是整个Benchmark里，数学、物理、计算机、文学、历史都有，还有我求职时碰过的面试题，以及工作中遇到的业务难题。

大致分布是这样：数学、物理、计算机理论知识各占10%，历史知识5%，生活常识5%，文学20%，Coding和工作问题合计40%。

这套比例，其实就是我整个人认知和经历的投影。

年初GLM帮我解决了不少Coding case，可计算机专业里Limits of Computation（可计算性的边界）的题，它答得并不好。

还有些偏门冷僻的历史问题，国产模型至今也答不上来。

比如我就阴暗地加入了

文学这块，模型对run-on sentence（两个本该独立成句的分句被硬塞进一句里）和sentence fragments（句子残片）会矫枉过正，碰上混乱的时序也容易读错。

最难缠的是衔接词滥用和修辞手法误判。

一来，手写文章里衔接词用得过滥，模型不太看得出来，因为它自己就这毛病；

二来，你用夸张修辞时，模型会说这段逻辑不通，还硬把梗或者人想表达的意思改写成平庸的版本。

case跑挂了，原因可以归到下面四类（源自Bloom's Taxonomy）：

事实性知识：孤立的基本知识节点，比如「法国的首都是巴黎」

概念性知识：各成分之间的关系与结构，比如因为A所以B的因果链。大模型出来之后，我又把它细分成语义、逻辑、时序几块

程序性知识：怎么做的方法、步骤、算法与技能

元认知知识：对自身认知的意识和监控，比如「我不确定」「我可能错了」。

这样归因，最大的好处是让非技术同学也能清楚看出模型哪儿不行，再据此去优化模型/Agent。不做优化的人不用学这套。

前文讲完，接下来直接动手，说说怎么搭一套属于自己的Benchmark。

对不写代码的人来说，电子表格就是现成的数据库。那套层级很深的嵌套JSON，完全可以压成一张平面表来用。

第一步是攒题。不用专门坐下来憋题，平时碰到什么就记什么，手头文档里有什么，也可以让模型帮你捋一遍。

用AI被坑一回，就记一条。当场把那段对话原封不动存下来，扔进固定位置——比如在备忘录里开个「AI 翻车」文件夹。隔几天再抄进题库，顺手补一句你原本指望它怎么回答，这句就是之后写判定规则的底稿。

开头先攒二三十条足够，没必要一上来就几百题。题目分布跟着自己平时用AI干的活走，哪个场景用得多，就多放几道。

第二步，在题库里放题目和判定规则。表格分成两页，可以直接复制进 Excel、Notion 或飞书表格：一页放题，一页记成绩。题库那页不动，成绩单每跑一轮就加一遍。

D列写判定规则，别写成「必须包含某个词」。我平时最常用的写法是三条：答案里必须点到什么；不能出现哪种做法；哪一点漏了就算挂。

拿 CASE-002 来说，规则如果写成「不得包含‘保证收益’」，靠谱的模型往往会补一句「没有哪只股票能保证收益」做风险提示，反倒被判成挂。

最后是成绩单那页。被测模型、Prompt 版本、运行环境，这三样都是变量，每次只能动其中一个。比如 CASE-001 只把 Prompt 从 v1.0 换成 v1.1，模型和环境都没碰，结果由挂变过，说明 Prompt 这次改对了。

Benchmark 被模型击穿只会越来越快，Coding 场景尤其明显。不过某个场景被击穿其实没关系，还有别的领域可以拿来探模型的边界。就算被SOTA模型打爆也不丢人，现在我这份Benchmark，更多是用来看各家的模型之间差多少。

另有一种偏门的玩法：交给 Agent 自动跑。手头要是有现成的 AI 助手，比如 Workbuddy、千问办公、豆包工作，最省事的做法是把你的 JSON 结构直接当任务说明书，让 AI 照里面的规则自己考自己，Python 脚本解析 JSON 这一步就省了。表格攒好之后丢给 Agent，让它按上面那个 JSON 的格式，逐行转成 case，存进 my_cases.json 这个文件。

接着给 Agent 发下面这段指令，想测哪个模型，就先在 Agent 里切到哪个模型：

单独起一个子任务（子 Agent 或新会话）作答，只给它 input 里的 system_prompt 和 user_input，别给 expected 和 evaluation。回答原样拿回来，判卷你来做。对照 must_include 和 must_not_include 逐条检查，写出命中还是没命中。按 score_weights 分项打分，每项引用回答原文做依据，总分对照 pass_score。不管过没过，都在 execution_history 末尾追加一条：model、prompt_version、score、passed、failure_reason、tested_at，旧记录不动。没过的，在 failure_reason 里写明属于哪一类：Facts 事实性 / Relations 概念性 / Procedures 程序性 / Meta 元认知知识。最后给我一张表：通过率、错误集中在哪一类、和上一次比哪些由挂变过、哪些由过变挂。

5年前做个 Chatbot，我得手搓 2000 条 Excel；现在一句话就能办到。

非结构化内容拆成结构化信息这件事，模型确实拿手，整条流水线跑起来也不用谁插手技术环节。

我这份 Benchmark 不方便公开。不过想照着这个思路做一份自己的，其实花不了多少工夫。

下回再有人对哪家模型开喷，碰上那种张嘴就说你犯了天条的，把测试结果甩出去，当场公开处刑就是了。

（封面是 ChatGPT 生成的，文字部分纯手工写的）