寻找最聪明的大模型:国内主流大模型能力深度评测

你多半遇到过这种场面：领导问「现在哪个国产模型最聪明」，你翻了一堆榜单，各家都说自己是第一，越看越没底。榜单里比的是别人出的题，你手上的活是写周报、改合同、扒表格、修代码，两回事。这篇不给结论，给一套能自己跑出来的评测流程：怎么定题目、怎么打分、怎么控制变量、什么情况下该直接放弃评测改用现成方案。

你多半遇到过这种场面：领导问「现在哪个国产模型最聪明」，你翻了一堆榜单，各家都说自己是第一，越看越没底。榜单里比的是别人出的题，你手上的活是写周报、改合同、扒表格、修代码，两回事。这篇不给结论，给一套能自己跑出来的评测流程：怎么定题目、怎么打分、怎么控制变量，以及什么情况下该直接放弃评测改用现成方案。

先说清楚立场：我们对「最聪明」这个词本身就不太信任。模型能力是分维度的，长文本稳定性和短指令遵循经常互相打架，写代码强和写中文公文强也很可能不是同一个选手。所以本文的目标不是替你选出一个冠军，而是让你在半天到一天内，用自己业务的真实输入，得到一个带条件的结论：在我的这类任务上，哪个更靠得住。想要现成的横向数字，去站内数据页看当时的口径，别把那些数字直接搬进你的汇报。

为什么直接抄榜单会翻车

榜单不是没用，是它的用途被夸大了。绝大多数公开榜单的题目来自公开题库，训练阶段见过同类题的概率不低，分数偏高不代表你的任务好使。更要命的是口径不统一：有的榜单给思维链，有的不给；有的按严格匹配打分，有的用另一个模型当裁判。这些差异叠在一起，横向比出来的名次其实没有可比性。

• 榜单看平均能力，你的任务往往只压在一个维度上，平均值高不等于这一项强；
• 不同榜单的 prompt 模板、评分方式、是否给推理过程都不统一，直接横向排名意义有限；
• 公开题库存在被训练数据覆盖的可能，分数虚高时你无法从榜单上看出来；
• 榜单不告诉你响应速度和长文本表现，而这两项经常是线上先出问题的地方。

第一步：把你自己的题目写出来

评测集的质量几乎决定结论的质量。别坐在工位上凭空编题，那只能测出模型的通用礼貌程度。正确做法是从历史工单、客服日志、群聊记录、代码仓库的 issue 里捞真实输入，连错别字和残缺的上下文一起保留，这才是模型上线后会遇到的输入分布。

1. 捞原始样本从工单、日志、聊天记录里抽 20 到 50 条真实输入，原文照搬，不要美化、不要补全缺失的上下文，先集中放进一个表格。
2. 按任务类型分组至少分成这几类：抽取结构化信息、长文总结、多轮追问、改代码或写脚本、中文写作与改写。每组样本量尽量均衡，避免某一类淹没其他类。
3. 写标答或可接受范围每条题后面写一句标准答案，或者写清楚哪些输出算合格。写不出标答的题直接删掉，它只会让评分变成印象分。
4. 区分硬指标和软指标硬指标是必须答对、答错就算失败的部分，比如金额、编号、字段名；软指标是语气、结构、详略这类差不多就行的部分。两者分开记分，别混成一个总分。

这一步做完，你会得到一张表：样本、任务类型、标答、硬软指标。这张表就是后面所有对比的地基。如果时间只够做一件事，就把这张表做扎实，后面打分和控制变量都是机械动作。

第二步：控制变量，别一边加提示词一边换模型

最常见的翻车方式是：A 模型用了精心打磨的提示词，B 模型随手一问，然后得出结论说 A 更聪明。这种对比等于没做。规则很简单，一次只动一个变量，同一套题、同一个提示词模板、同一档温度参数，只换模型。

提示词模板

所有候选模型共用一份，不要给谁单独优化，除非你要测的就是提示词适配成本。

输出长度上限

设成同一个值。不设的话，爱长篇大论的模型会显得更完整，其实只是话多。

温度参数

抽取类任务调到接近确定输出，创意类任务放宽，但所有模型必须同一档。

重复次数

同一题至少跑两到三次，记录结果是否漂移，只跑一次就下结论的评测基本没用。

失败样本留存

把答错的原文和输出完整存下来，比只记一个通过率有用得多，后面排查全靠它。

# 控制变量的最小做法示意
# 同一份题目文件、同一个模板、同一档参数，循环换模型名
for m in model-a model-b model-c; do
  run_eval --task tasks.jsonl --template tpl.txt --temperature 0 --model "$m" --out "out-$m.jsonl"
done
# 跑完对比 out-*.jsonl，先看失败样本，再看总量

第三步：打分表怎么设计才不糊弄自己

打分最容易糊弄自己的地方，是把所有题拉平算一个总分。正确做法是按任务维度加权，权重来自这个任务在你业务里出现的频率。周报改写占你八成工作量，那它在总分里的权重就该高，哪怕它在题库里只占一小部分。权重的来源是业务量，不是你的个人偏好。

• 请两三个人各自盲评，隐藏模型名字，避免先入为主，尤其要防止「我知道它贵所以它更好」；
• 结论必须带条件：在我这种输入长度、这种语言、这种格式要求下，它表现更好；
• 把波动大的题单独列出来，这类题往往说明需求本身没定义清楚，不是模型不行；
• 打分表跑完先别急着汇报，隔一天再看一遍失败样本，经常能发现评分标准自己的漏洞。

如果你不想自己造打分表，站内工具目录里有一些现成的评测与对比工具值得先看看，能把记录和回放自动化掉一部分；各家模型在具体任务上的历史表现数据，也可以到站内模型资料库对照当时的记录。但记住，别人的记录只能当参考，你的输入分布只有你自己知道。

哪些情况不值得你亲自评测

评测本身是有成本的：搭题、跑批、盲评、写报告，一套下来一两天起步。有些场景压根不值得这么干，早点承认反而省事。

• 任务只是分类、打标、关键词提取这类边界清晰的小活，小模型微调后可能就够用，绕开大模型横评更省事；
• 只是内部试用、调用量极小，先用现成平台切几个模型试两天，凭手感选一个，不必建评测集；
• 数据不能出内网，那就先解决私有部署问题再谈评测，评测框架可以照搬，但样本不能外传；
• 需求每隔几周就变，先固定需求再评测，否则评测集刚建完就作废，白忙一场；
• 你已经有一个稳定在用的模型且没人抱怨，那就别为了「可能更聪明」去折腾迁移，迁移的隐性成本通常被低估。

评测跑完之后怎么让它长期有用

一次性的评测报告，三个月后就没人看了。真正有价值的是把评测集当成活文档养着：每出现一次线上翻车，就往里补一条样本，标注清楚当时的输入和期望输出。这样半年下来，你手里就有一份别处买不到的、专属于你业务的对照集。

还有一件事经常被忘：把评测结果和成本、响应速度放在一起看。单看聪明程度，很容易选到一个贵且慢的选手，最后业务方抱怨的不是答得不好，而是太慢太贵。站内价格追踪页面能帮你核对当时的计费口径和变动情况，速度类指标可以到站内速度测试页看同期记录，别用记忆里的数字做决策。

评测的产出不是「谁最聪明」，而是一句带条件的判断：在我这类输入上，谁更稳、更便宜、更跟得上节奏。