1. 评测这事为什么越做越糊涂这两年问“大模型评测怎么做”的人明显变多了但聊下来发现一个挺有意思的现象大多数人并不是不知道有评测工具而是不知道评测结果到底该怎么信、怎么用。有人说“我的模型跑分很高”换了个测试集直接掉一半有人说“评测集是公开的”结果训练数据早就见过这些题还有人拿着 rouge、bleu 在那跟大模型较劲输出结果全是套话分数还挺高。这些场面我都经历过不算罕见。问题的根源不在于“评测”本身难而在于很多人把“评测”理解成了“跑分”。跑分只是形式评测的核心是定义你关心什么能力找对能反映这个能力的任务用能区分模型优劣的指标然后对结果做可信的解读。缺了任何一环分数都只是一堆数字。这篇文章我就按自己的实操经验把大模型评测从头到尾拆开来讲。适合三类人看刚接触大模型、想搞清楚评测流程的初学者需要给团队搭一套评测方案、被领导追问“模型到底行不行”的工程师以及纯粹想搞明白“跑分到底骗没骗人”的好奇派。我不会堆一堆术语尽量用大白话把每一环的逻辑讲透最后会给出可以直接抄的评测模板和避坑清单。先给一个总览一套能用的评测体系由五个部分组成——评测目标定义、评测集设计与构建、评测执行环境、指标计算与结果解读、评测集维护。后面所有内容都围绕这五个部分展开。你就把评测当成一次考试命题先想清楚考什么科目再出题然后组织考试最后判分考完还要复盘题目出得好不好。这套逻辑放到大模型评测上是通用的。2. 先想清楚你到底要测什么2.1 能力维度的拆解很多人一上来就找“有没有一个总榜”这个思路本身就容易出问题。大模型的能力是分层的基础能力、垂直能力、安全能力、工程能力每一个大类下面还分很多子项。你评测的目标不同关心的子项就会完全不同。基础能力通常包括语言理解能不能读懂一段话、知识问答常识、百科类知识是否准确、逻辑推理数学题、因果推断、条件判断、代码生成能不能写出可运行的代码、多轮对话上下文理解与连贯性。垂直能力就是针对你的具体业务场景比如法律条文理解、医疗问答、金融报表分析、代码审查、客服话术生成等。安全能力包含的内容更多有害内容拒答、幻觉控制、越狱攻击防护、隐私信息不泄露这些都是重点。工程能力则涉及上下文长度是否真的能支撑、输出速度、并发能力、模型对输入格式的敏感程度等。要做评测第一步不是选榜单而是坐下来把你的需求场景挨个列一遍。比如说你想在客服系统里用大模型那你关心的能力就是多轮对话、意图识别、情绪安抚话术、格式化的回复输出、拒答能力回答不了的时候不要瞎编。这时候拿 MMLU 这种通用知识集去测基本没有意义它考的不是你业务需要的东西。我见过一个最典型的翻车案例某团队想做文档问答助手评测的时候选了三个通用能力测试集模型跑出来的效果“还可以”但实际接上线后用户拿公司合同来问模型把赔偿条款理解反了。事后复盘发现评测集里压根没有任何长文本、专业术语、否定句式的内容。不是模型不行是评测目标定义错了。所以我在做评测方案时第一步永远是输出一份“能力清单”每一条都要写上这个能力为什么重要、对应什么业务场景、如果模型在这个能力上不行会造成什么后果。这份清单就是后面所有工作的地基。2.2 评测类型的选择评测目标定义清楚之后还要确定评测类型。按数据的来源和标注方式主流做法分成三类公开基准测试、自建评测集、人工对抗评测。公开基准类的特点是方便、有对比性比如 MMLU、C-Eval、GSM8K、HumanEval、BBH 这些。优点是拿来就能用社区认可度高方便跟别人家的模型横着比。缺点是公共数据有泄漏风险现在很多模型训练时就已经把这些题“背”过了跑出来的分高不代表能力强另外公开集的任务形式固定测不出你业务场景里的真实表现。自建评测集是业务评测的主力。基于你自己的业务数据构造问题用真实场景里的输入输出格式来评测。这种评测的可信度最高但代价是要花人力去做标准化、标注、审核。人工对抗评测是另外一条路让评测人员扮演攻击者去拷问模型、诱导模型犯错主要用于安全、边界场景的测试。从投入产出比看我的建议是你要是只想知道某个开源模型能不能用跑公开基准就够了你要是准备把模型接进业务线那就必须做自建评测集你要是做金融、医疗这种高风险场景人工对抗评测不能省。3. 评测集构建成败的关键环节3.1 优质评测集的三条标准评测集是整条评测链路里最重要的资产。很多人觉得评测集就是“找一堆问题标准答案”这个理解太浅了。一个真正好用的评测集必须满足三条标准相关性、区分度、稳定性。相关性是指评测内容必须贴近真实任务。你做客服问答评测问题就应该是客户真的会问的话而不是从百科上抄来的冷知识。区分度是指评测集能把不同水平的模型拉开差距。如果满分100分的评测集GPT 考99分你微调的模型也考98分说明题目太简单根本没有区分能力。真正高质量的评测集应当让头部模型得分在70-85分之间留下足够的分数空间去观察模型之间的差距。稳定性是指同样的模型、同样的评测流程跑两次结果应该基本一致。如果波动太大说明评测集本身有问题测试结果不可信。这三条标准说起来简单做起来全是坑。我遇到过评测集构建完发现所有题目都是一个问法——“请解释一下什么是……”模型背模板就能拿高分。这就是相关性和区分度双失。后面我会详细讲题目设计和验证方法。3.2 测试题目的来源与生成测试题目的来源我认为优先级从高到低是真实业务数据、业务专家编写、模型辅助生成人工审核。真实业务数据永远是最优先的。比如你有一批客服聊天记录从中抽问法、抽场景、抽用户意图这种题目的真实感是凭空写不出来的。第一种方法是直接改造真实数据。拿一段客服对话把用户的问句提取出来作为评测问题把优秀客服的回答整理成参考答案。这样做的好处是评测内容天然符合业务场景数据分布也是真实的。需要注意的是脱敏凡是涉及用户隐私的信息一律要处理掉。第二种方法是业务专家编写。让懂业务的人根据实际经验设计问题。他们知道用户最常踩的坑、最关心的事情写出来的题更有针对性。这类题目的质量取决于专家的投入程度建议给出固定的题目模板帮助专家快速统一输出格式。第三种方法是用大模型生成候选题目再由人工筛选。这适合规模化扩充评测集。操作上可以写一个提示词约束大模型按“场景意图难度问题参考答案”的格式出具题目然后由业务人员筛选合格的部分。这里有个关键原则题目可以模型生成但参考答案必须人工校正。模型生成的答案本身可能有误拿来当标准答案会让评测结果失真。我实际做过一次评测集扩充。源数据是客服系统里 1000 条脱敏对话我先从中抽了 200 条完整问题对作为种子题然后让大模型基于这些种子题改写不同问法再让业务专家对扩充出来的 800 条逐一做标记最后保留了 240 条合格题目。整个过程花了两天但评测集的质量比直接用现成数据集高了一个档次。3.3 参考答案的标注策略很多人忽略参考答案的质量这是评测结果跑偏的一个重要原因。参考答案并不是“唯一的标准答案”。对于知识问答类题目答案通常有确定性可以由专家给出标准答案。对于开放性问题比如“帮用户写一封离职邮件”参考答案应该是一个评分维度比如是否包含感谢、是否说明离职时间、语气是否得体、是否有交接意愿。评测时按维度打分而不是硬比文本相似度。标注方式上我见过比较成熟的方案是双人标注仲裁。两张独立的标注结果一致性达到一定阈值这道题才算通过校验。如果两个标注差异很大就需要第三人介入讨论定出最终参考答案。这个过程费时费力但非常值得投入。另一点值得提醒参考答案需要定期更新。业务是变化的评测集里的参考答案也要跟着业务迭代。之前我们的客服评测集里处理退货的参考话术是“请联系人工客服”后来业务升级支持了自助退货这个答案就必须同步更新否则模型明明答对了评分却判错评测集反而成了拖后腿的东西。4. 评测流程的落地执行4.1 评测类型与执行环境的选择评测集就绪后紧接着要决定评测怎么跑。这里我建议把评测分成两类离线评测和在线评测。离线评测就是拿写好的题目去测模型等模型跑完再去算分这是绝大多数场景下的主力评测方式。在线评测则是把模型部署到真实的业务环境中用真实的用户流量去观察模型的表现。离线评测的好处是可控性强、可复现、能做回归对比。所有模型的版本迭代、不同参数的对比都应该在离线评测集上先跑一轮再说。在线评测回答的是“模型在真实场景中到底行不行”的问题但它的成本高、周期长、干扰因素多不适合做频繁对比。执行环节要考虑的事情还挺杂的。第一是并发设置大批量调用模型接口时要控制并发数避免被限频。第二是超时控制每个问题必须设超时时间防止单个坏请求拖垮整轮评测。第三是随机种子涉及模型采样的时候固定随机种子保证结果可复现。第四是输出清理单轮问答模式的评测要禁用模型联网搜索否则测出来的结果就不纯粹了。评测框架方面我现在主要用两个。一个是 OpenCompass开源大模型评测框架它集成了大量公共评测集和评测指标适合公共基准测试配置好模型接口就能跑。另一个是自建的评测管线针对自建评测集设计核心就是读取题集、调用模型、记录结果、计算指标。自建管线不复杂但每一步都要可控因为业务评测里“过程可追溯”非常重要。4.2 逐题评测的实操流程逐题评测的具体流程我用过一个比较成熟的做法拿最简单的“单选知识题”举例第一步构造输入。每道题要先定义好输入格式比如一个字典结构包含题号、问题内容、选项列表、参考答案、评测维度。然后通过 Prompt 模板把这道题转成模型的输入文本。第二步调用模型。保留接口的原始返回包括完整的输出文本、返回的 token 数量、耗时。这些数据后面分析时都有用不要只存一个最终答案。第三步判定结果。判定方式分两类自动判定和人工判定。单选题可以使用正则匹配答案选项。问答题可以用大模型当裁判把“问题参考答案待评模型回答”一起交给裁判模型让其按维度打分。人工判定用于复杂场景比如审查模型在恶意诱导下的反应这时候机器判不准只能靠人。第四步记录日志。每道题的输入、输出、判定过程、判定结果全部落盘。日志的作用是事后可查当评测结果异常时能直接定位到是哪道题出了岔子。第五步汇总计算。把每个维度下的得分汇总最终形成阶段性的评测报告。这里要特别注意不能把不同能力的得分混在一起算平均分那是糊弄自己。每个能力维度应该单独算分单独展示。4.3 大模型裁判的交叉验证现在大模型当裁判LLM-as-a-Judge的做法非常流行核心思路是拿一个强模型比如 GPT-4、Claude 或你觉得靠谱的其他模型来评估目标模型的回答质量。用得好能省大量人力但用不好会引入新的误差常见的坑我踩过不少。第一个坑是顺序偏差。把“模型A回答”放前面“模型B回答”放后面裁判可能倾向于认为排在前面的更好。解决办法是在对比评测时做两次测试调换回答顺序再跑一遍取一致的结果作为最终结论。第二个坑是自我偏好。裁判模型可能更青睐“跟自己风格相似”的回答。比如裁判模型答案比较啰嗦就会给啰嗦的答案更高分。解决思路是使用多个裁判模型做投票或者限定裁判只能依据评分维度打分降低主观偏好。第三个坑是分数幻觉。裁判模型面对质量差不多的两个答案可能给出波动很大的分数。所以别依赖单次打分做多次推理取平均同时把分数差异过大的样本拎出来人工复核。我在业务评测里总结了一条操作规范凡是裁判模型打出的分数差异超过阈值比如 10 分制里差异超过 2 分一律进人工复核名单。人工复核不是重新评分而是判断裁判评分是否合理校准裁判的评分标准。跑过两三轮之后裁判模型的评分稳定性会好很多。5. 评测指标的计算与结果解读5.1 不同任务的指标选择评测指标不是越多越好而是要找对。不同的任务形态匹配的指标差异很大用错指标会得出误导性的结论。生成类任务例如摘要、翻译、问答的开放式回答传统指标是 ROUGE 和 BLEU但这两个指标在大模型时代已经严重失真。大模型可以换一种表达方式表达同样的含义字面重合率低但语义完全正确ROUGE/BLEU 就会打出偏低的分。所以生成类任务我更推荐使用语义相似度向量比较或者干脆用大模型裁判评分本质上是评估语义层面的质量而非字面匹配。多选题和填空题这类的判别式任务指标用准确率也就是答对的题目数除以总题目数简单直观。代码生成类任务则是看编译通过率和单元测试通过率测试用例覆盖得越全面这个指标就越有说服力。RAG检索增强生成任务还需要看检索命中率和引用正确率不能只看最终回答是否流畅关键信息是否来自检索结果才是重点。上下文能力评测时有人用“段落召回”的方式来测给模型一篇长文档然后询问文中位置很靠后的信息。这里的指标不只有准确率还要记录模型第一次给出正确答案所需的输入长度。上下文长度上限从来不是一个硬数字而是一条能力衰减曲线。你测出来上下文窗口宣称 128K实际在 64K 时准确率就开始明显下滑那有效上下文就是 64K而不是标称的 128K。5.2 结果解读的常见误区拿到评测分数之后解读阶段同样容易翻车。第一个常见误区是“只见分数不见误差”。评测有误差任何评测都有。同一模型跑两次不可能完全一致差别来自采样随机性、并发环境影响、评测集本身的偏差。所以报告里必须标注置信区间或者多次结果的范围你看到的分数是一个区间而不是一个点。第二个常见误区是“拿总分对比模型好坏”。不同能力维度之间的分数不可比不该平均成一个数。我的习惯是构建能力雷达图每个维度单独展示。如果两个模型总分一样但一个强在代码、一个强在对话它们的使用场景完全不同不能因为总分相同就当它们一样。第三个常见误区是“忽视坏例分析”。分数只是一个统计结果真正有价值的是那些扣分的样本。我在每次评测完都会专门抽出失败案例一条条看模型为什么错。有时候会发现评测集本身有问题比如参考答案错误或者题目表述有歧义。不做好这一步你会花大量时间“优化模型”到最后发现其实是在“优化一个错误的评测集”。第四个常见误区是“横向对比时忽视模型外部条件”。同样一个模型跑在 V100 上和跑在 A100 上因为推理框架的差异、量化策略的不同最终效果可能不一样。横向对比所有模型时必须声明硬件环境、推理框架、量化配置否则对比意义不大。你拿着两个模型在不同环境下跑出来的结果比优劣比了个寂寞。6. 实战方案搭一套最小的评测体系6.1 直接可用的评测模板理论说了不少我直接给一套最小可用方案。这一套适合“只有一个大模型 API想快速知道它行不行”的场景。评测集规模 50 题知识问答单选 30 题开放性问答 20 题拒绝回答类测试。一共100题足够了。知识问答覆盖业务常识开放性问答覆盖真实任务拒绝回答类测试用于检测模型在触及敏感或无知领域时是否懂得拒答。准备一份参考答案文件就够了。运行方式写一个 Python 脚本流程如下。第一步读取题集。第二步逐题调用大模型接口。第三步保存原始输出。第四步调用裁判模型评分。第五步汇总输出指标包括准确率、维度得分、失败案例列表。Prompt 模板方面最核心的部分是把“评测问题”和“参考答案”一起提供给裁判模型并要求分维度打分。建议控制裁判模型的输出格式强制其输出 JSON方便后续解析。输出的维度包括相关性、准确性、完整性。评测结束后输出三样东西一个分数汇总表包含每个维度的得分一个失败案例列表按失败类型分类一个对比基线记录同一评测集下参考模型的表现。这就是一套完整的微观评测闭环。6.2 工程化评测体系怎么搭如果你不是评测一个模型而是要在团队内部长期评测多个模型、多个版本那就需要更工程化的体系。我建议按下面三个层面来搭。首先是评测资产层。包括评测集数据、参考答案、评测配置。所有数据都要有版本管理每次评测基于固定版本去跑。评测集文件采用 JSON 格式一条题目的完整结构包含任务 ID、任务类型、问题内容、参考回答、评测维度、难度等级、来源标识。这么设计是为了可追溯、可筛选、可扩展。其次是评测执行层。对应自动化脚本支持批量评测、失败重试、并发控制、日志记录、结果落库。评测执行的过程要做到完全自动化一键触发、全程无人工干预。跑完自动生成结果文件。最后是报告分析层。把结果文件可视化绘制趋势图、能力雷达图、对比表同时把失败案例汇总成待分析清单。这一层主要服务于决策模型到底能不能上线、模型的哪个版本值得保留、微调方向应该聚焦哪个能力。工程化评测是一个持续演进的过程。也可能一开始评测集只有几百条后来逐步扩充到几千条一开始只能测离线效果后续接入在线反馈。但底层的逻辑框架不需要变资产、执行、报告这三层是稳定的。7. 评测集防泄漏与长期维护7.1 数据泄漏的识别与规避公共评测集有一个绕不开的问题数据泄漏。大模型训练用的公开数据里几乎必然包含常见的评测题。模型对这些题的“高分”并不能证明它的能力只能证明它背过答案。数据泄漏的识别并不容易。一个简单有效的测试方法拿一个你确认没怎么训练过的小模型跟大模型对比跑同一个公开评测集。如果大模型分数高得离谱而且你怀疑它有记忆就换一批高相似度的题目去测。换题之后分数明显下降说明原来的高分大概率是记忆而不是能力。规避数据泄漏的思路有几个。第一多用自建数据集特别是基于内部业务数据构建的评测题这些数据基本不会出现在训练语料里。第二使用动态评测集定期混入新题、换掉旧题让模型无法靠“刷题”取胜。第三做能力测试时尽量设计需要推理的任务而不是考知识记忆。知识记忆类题目最容易受泄漏影响推理类题目即使见过类似题型也不一定能直接背出答案应变能力和逻辑能力才是测评的核心目标。7.2 评测集的生命周期管理评测集不是一次性产品它的生命周期管理值得单独拿出来讲。第一件事是版本管理。每次修改评测集都要保存一个独立版本并记录变更说明。新老版本之间要能对比比如模型在 v1 上得 80 分在 v2 上得 75 分需要知道是模型真的退步了还是因为评测集的难度提升了。只有评测集版本清晰这种对比才有意义。第二件事是滚动替换。使用固定不变的评测集会带来“评测过拟合”的风险长期盯着同一批题去优化模型很容易走入只为刷分的歧途。正确做法是每次迭代逐步替换百分之十到二十的题目既保持纵向可比性又注入新鲜度。第三件事是质量复审。每隔一个周期把评测集里的题目重新审核一遍检查是否有题目表述过时、是否有标准答案需要更新。业务发生变化后可能旧题已经不能反映当前需求了。质量复审的频率取决于业务变化的速度业务迭代快的建议每季度做一次。另外还有一件容易被忽略的事评测集的权限管理。评测题和参考答案是核心资产要注意控制接触面。见过一些团队公开评测集后模型训练方直接把题集拿来训练评测结果就完全失去公信力了。如果是内部重要评测评测集必须严格保密。8. 评测机构与自动化实验的进阶玩法8.1 评测集自动化生成的技巧评测集构建的一大难点是题目数量往往不够。手工编写太慢靠人肉攒题又不现实自动化生成是一个必经之路。我用过比较顺手的方案种子题扩写加场景组合、再人工校准。种子题扩写是指用一组高质量种子题让大模型按同义改写、场景迁移、难度调整等方式生成新题。比如种子题里有个问题是“退货的运费谁承担”可以扩展出“收到货破损怎么办”“换货要自己出邮费吗”等多个变体。这种方式产出量很快但必须配合筛题和改题流程。场景组合是指把“场景”“用户意图”“实体数据”三个要素做笛卡尔积排列组合。比如场景包含线上购物、线下门店、电话客服用户意图包含退换货、投诉、咨询实体数据包含商品名、地区、金额。组合出来的题目数量可以非常庞大而且结构统一、覆盖面广。这种题比较适合做批量评测但机器生成感较强需要人工润色自然度。自动生成的题目必须过一遍“人工筛选人工改题”的环节。我自己的统计是机器生成 100 条经过筛选和修改后能用的差不多 40 到 50 条不合格的淘汰率还是挺高的。不过即便丢了一半整体效率依然比纯人工快很多。8.2 自动化评测与模型选型的实战参考在团队里做模型选型时我套过一整套自动化评测流程。目标很明确从三个候选模型里选出一个适合业务线的主力模型。评测流程如下你可以直接参考这个思路。第一步整理业务高频任务清单。把线上真实用户请求按频率排序挑出 Top 20 个任务类型对应生成评测问题各 20 条共 400 条。第二步把三个候选模型部署到同样的推理环境统一用相同的 Prompt 模板。全流程脚本化逐个模型跑完全部评测题。第三步用裁判模型给开放性题目打分设定差异阈值超阈值的样本人工复核。第四步汇总每个模型在每个任务类型上的得分和排名。第五步结合硬件成本、推理速度、并发能力给出综合推荐。这一套跑下来大概需要一两天相比以前全靠人肉看效果靠谱得多。选了模型之后再针对弱项做提示词优化整个选型闭环就完整了。9. 我的几点小心得做评测这几年我最大的体会是评测不是证明模型“好”的工具而是帮助团队搞清楚模型“哪里不行”的工具。很多团队评测做到最后流于形式就是因为出发点就错了——他们想让评测去证明预算花得值而不是坦然面对模型的短板。换个角度之后你会发现评测的产出不是一纸分数单而是一份“缺陷地图”告诉你该往哪个方向发力。最后再分享一个小技巧。每个评测集构建完成后先不急着测模型拿已知好坏的几个参照模型各跑一遍把分数的合理性验证一下。好的模型应该明显高于差的模型如果差距拉不开说明评测集设计有了问题要及时打回重构。把这道“质检工序”前置后面省下的时间会非常可观。评测这件事说到底就是在“成本”和“信任”之间做权衡。建评测集费钱费人但它是你跟模型之间的信任基石。把前面说的这些细节做到位你评测出来的任何一个结论都不会心虚。