自建AI Benchmark的实用指南：从真实场景出发
几周前，一位在模型行业工作的朋友提到，他有一套自用的基准测试集，其中包含不少极其冷门的题目，能更精准地评测新发布模型的实际表现。在当前各类榜单被模型刷分的大环境下，这套私有测试集的价值凸显。
当被问及是否愿意开源这套测试集时，朋友表示：“任何公开的基准测试集都会被模型刷榜变成废纸，这类工具只适合自己用来研究和测试。” 虽然他不愿公开自己的私有测试集，但愿意分享一套方法，教大家如何结合现有工具搭建属于自己的基准测试集。
他提到，搭建个人基准测试集主要有三个原因：
1. 让自己在评判模型时更有底气：这套测试集让他在年初指出某模型的功能缺陷，以及后来批评另一模型的代码能力不足时，无需担心被网民指责“挑刺”，有了充分依据。
2. 满足好奇心：想知道模型何时能替代自己的大部分工作。
3. 积累个人知识库：通过测试集沉淀自己对模型能力的认知。
好的基准测试集源自真实场景
在使用大模型的过程中，很多人都遇到过类似问题：修改提示词后感觉效果变好，但不确定是不是心理作用；换了一款号称顶尖的新模型，结果在日常任务上表现反而变差；跑了几个经典测试场景效果还行，一到实际使用就出现各种错误。这些问题从传统自然语言处理时代就存在，而基准测试集的意义就在于此：要完整验证模型在某个场景下的实际能力，不能只靠几个测试用例就下结论，必须尽可能模拟真实场景的状态。
搭建基准测试集的目的，一是获得评判的立场，二是明确评判的标准。单纯显示分数没有意义，关键是要分析数据分布，才能知道下一步该调整提示词、更换模型，还是优化流程。优秀的基准测试集，一定是从真实场景中积累出来的。
过去工业场景中，很多基准测试集是从客户实际案例中人工提炼泛化而来；现在有了大模型，不少人会从公开数据集里抄题目，或者让模型根据一个案例批量生成测试用例。但在他看来，任何不贴合实际场景的基准测试集都站不住脚。个人用的测试集，应该完全由自己遇到的问题累积而成，至少第一版必须从真实场景中总结，不能凭空造。如果真需要批量生成案例，建议用能力强的模型去测试能力弱的模型。
如何设计基准测试集和测试用例
朋友的基准测试集里，部分常识类题目甚至能沿用至新一代模型。他的测试集能长期有效，原因在于覆盖了广泛的应用场景。他本人是物理和计算机专业双修，还辅修了文学，所以测试集覆盖了数学、物理、计算机、文学、历史、求职面试题和工作中的业务难题。具体分布为：数学、物理、计算机理论知识各占10%，历史知识5%，生活常识5%，文学20%，代码和工作问题占40%。这个分布完全体现了他的个人认知和经历。
比如，虽然年初某模型解决了他不少代码类测试用例，但无法很好回答计算机专业中关于可计算性边界的问题；不少冷门历史问题，国产模型至今也答不上来，比如清军入关的细节、二战中俄罗斯的战略决策，甚至KV-1坦克能否击穿百夫长坦克正面装甲这类问题。
在文学方面，模型容易对连写句、句子残片矫枉过正，还会误解混乱时序，最大问题是滥用衔接词和错判修辞手法。模型本身就习惯滥用衔接词，所以很难识别手写文章中的这类问题；当使用夸张修辞时，模型会判定为逻辑有问题，还会强行把梗或想表达的内容纠正为平庸表述。
如果测试用例没通过，可以从四类维度归因，参考认知分类法：
事实性知识：孤立的基础知识点，比如“法国首都是巴黎”；
概念性知识：各部分之间的关系与结构，比如因果链，大模型出现后，还可细分语义、逻辑、时序等维度；
程序性知识：做事情的方法、步骤、算法与技能；
元认知知识：对自身认知的意识和监控，比如“我不确定”“我可能错了”。
这种归因方式的好处是，让非技术人员也能清楚知道模型的不足，后续可根据结果优化模型或智能体。不需要优化的人则不需要深入学习这套方法。
如何搭建属于自己的基准测试集
理解了前面的内容，接下来就可以动手搭建自己的基准测试集了。对于非技术人员来说，电子表格就是最好的数据库，可以把复杂的嵌套结构简化成表格。
首先是收集测试用例。不需要专门去想，平时遇到的AI使用问题，比如被AI坑了一次，就记录下来，把那段对话原样保存，比如在备忘录里建一个“AI翻车”的文件夹。隔几天把这些案例抄进题库，再写一句希望模型给出的答案，这就是后续判定规则的基础。起步时攒二三十个就够了，不需要一开始就做几百个，用得多的场景就多放些案例。
其次，把题库分成两页，一页放测试用例，一页记成绩。题库保持不变，每次运行后，把结果加到成绩单里。判定规则不要写成“必须包含某个词”，最常用的方法是：答案里必须提到什么，不能出现哪种做法，漏了哪一点就算失败。比如，如果案例要求“不得包含‘保证收益’”，模型可能会说“没有哪只股票能保证收益”做风险提示，这样反倒会被判失败，所以规则要更灵活。
最后是成绩单页，被测模型、提示词版本、运行环境这三个是变量，要求每次只改变其中一个。比如，只把提示词从v1.0换成v1.1，模型和环境都不变，结果从失败变成通过，说明提示词改对了。
你的基准测试集很快会被模型击穿，尤其是代码场景，但某个场景被击穿没关系，还有更多领域可以测试模型的边界。即使被顶尖模型打爆也不丢人，现在的基准测试集更多是用来对比各家模型之间的差距。
用智能体自动运行基准测试集
如果手头有现成的AI助手，最方便的方法是把JSON结构当任务说明书，让AI按照规则自己测试。不需要写代码解析JSON，把表格整理好后，直接发给智能体，让它按照JSON格式把每一行转成测试用例，存成文件。然后给智能体发送以下指令（想测哪个模型，就先在智能体里切换到对应模型）：
单独起一个子任务作答，只给它输入里的系统提示和用户输入，不要给预期答案和评估。回答原样返回，由你做判卷。
对照必须包含和必须不包含的内容逐条检查，写出命中还是没命中。
按分值权重分项打分，每项引用回答原文做依据，总分对照通过分数。
不管过没过，都在执行历史末尾追加一条：模型、提示词版本、分数、是否通过、失败原因、测试时间，旧记录不动。没过的，在失败原因里写明属于哪一类：事实性/概念性/程序性/元认知知识。
最后给我一张表：通过率、错误集中在哪一类、和上一次比哪些由挂变过、哪些由过变挂。
5年前要做一个智能体，得手搓大量表格，现在只需要一句话就能完成。模型非常擅长把非结构化内容拆解成结构化信息，自动化操作不需要技术介入。虽然这位朋友的基准测试集不能公开，但按照这套方法自己做一份并不难。下次有人说你批评模型是“犯了天条”，直接把测试结果甩出来就好。
