有一类困惑我见过太多次模型在榜单上名列前茅一接进业务就各种翻车模型在公开测试集上分数涨得漂亮换一批内部数据立刻打回原形。大模型评测这事儿看着人人都能做打开 HuggingFace 拉几个数据集就能跑出一份报告可真到了要回答“这模型能不能上生产、能不能替代我现在的方案”的时候你会发现分数根本不会说话。这篇东西不打算给你复述论文里的评测公式而是把我这几年来做大模型评测踩过的坑、沉淀下来的流程以及我认为最容易被低估的环节完整梳理一遍。无论你是刚开始接触大模型评测还是已经在做微调验收、选型对比、Agent 评测集构建这篇文章应该都能给你一些可以直接落地的思路。1. 评测大模型之前先想清楚“这一轮测给谁看”我见过不少团队把“评测”当成一个默认动作模型拿回来先跑一遍 MMLU、GSM8K、HumanEval分够高就认为可以用了。这种做法的问题在于评测目标的缺失会直接导致评测设计的错位。当你不知道结果要服务什么决策时你只是在收集数字不是在评测。1.1 先确认产出物是一份报告、一个选型结论还是一套回归数据同样是“测一下模型”三种目标对应的做法完全不同如果是给管理层看的能力全景报告你要测的是知识广度、推理深度、多语言能力、安全边界倾向使用通用基准加结构化人工评测。如果是给技术选型决策用你要测的是业务场景上的真实表现必须构建贴近业务的评测集最好从生产日志里抽样。如果是给微调迭代做回归你要的是稳定、可复现、能区分小差异的评测集问题数量要够难度梯度要清晰不能今天换条 prompt 明天结果就乱了。我在实际项目里最常遇到的情况是团队想用一套评测集同时解决选型和回归两个问题最后两边都没测好。选型需要业务真实度高的样本回归需要足够敏感、能测出 0.5 分差异的样本两者样本结构完全不同。所以每次开始评测前我都会先写下一句话这轮评测我要回答什么问题谁会根据结果做什么决定。这句话越具体后续越少走弯路。1.2 能力边界与业务场景要对齐通用大模型的能力边界分布很不均匀。一个模型可能在代码生成上很强但在中文长文档理解上发挥不稳在知识问答上表现好一到开放式写作就开始跑题。评测时必须把这些能力维度和你的业务场景做一张映射表列出每个场景依赖哪些模型能力再针对性地设计评测任务。举例来说如果你的业务是客服质检核心能力是语义理解、意图识别、摘要抽取、指令遵循那 MMLU 这种知识竞赛式评测对你的参考价值就很有限。你需要构造的是“客户问题-标准回复动作-参考依据”这样的结构化评测集测模型能不能在限定条件下给出规范输出。评测脱离了业务场景就是在给模型做体检不是给方案做质检这两者要分清。1.3 大模型评测的四个常见误区第一个误区是用公开榜单代替评测。榜单反映的是某个固定测试集上的相对表现而公开测试集普遍存在污染风险模型可能已经在预训练阶段见过这些题。我见过有些模型在某个知名基准上分数惊人换几道思路相近但表述不同的题表现立刻下降一大截这就是典型的测试集污染。第二个误区是评测集随便搞几百道题就觉得够了。评测集的广度和难度分配直接决定结果可信度。几百道题如果全部集中在同一个知识点测出的只是模型在这个知识点上的表现不是整体能力。第三个误区是只看平均分不看分项和方差。平均分高不代表稳定。同一个模型在不同 prompt 写法下的输出可能天差地别评测时如果不测 prompt 敏感性平均分很容易失真。第四个误区是脱离部署环境看评测。同样的模型FP16 还是 INT8 量化、vLLM 还是原始 PyTorch 推理、上下文窗口设多少都会影响实际输出质量。这一点后面部署评测部分我会详细展开。2. 评测集构建最费时间也最容易被低估很多评测报告不靠谱根子都在评测集上。公开 benchmark 有它的价值但靠它解决不了业务问题。真正让评测有说服力的是你自己构建的那部分评测集。2.1 公开基准怎么选知道每个 benchmark 在测什么我没有一上来就否定公开基准它最大的价值是给你一个坐标系让你知道某个模型在行业里的相对水位。但用之前得搞清楚每个基准到底在测什么以下是我常用的几个基准主要测量维度我实际使用时的提醒MMLU知识广度、多学科理解题目曝光率高污染严重分数仅供参考C-Eval中文综合知识中文场景可用但同样存在数据泄露风险GSM8K数学推理、步骤拆解只测最终答案会忽略推理过程建议解析完整解题链HumanEval代码生成、函数级正确性样本量少通过率波动大需配合 Passk 看分布MMLU-Pro复杂推理、多步逻辑相对更难区分度好一些但跑分成本也更高TriviaQA事实记忆、检索依赖很多题靠训练数据记忆就能答测不出推理使用公开基准时我的惯例是每个模型至少跑两遍一遍用默认 prompt一遍用统一规范的 prompt 模板对照结果差异。差异超过一定阈值就说明模型对 prompt 敏感选型时要多留个心眼。2.2 业务定制评测集的构造流程公开基准只是起点业务评测集才是核心资产。我的构造流程一般是五步第一步任务拆解。把业务里的核心任务拆成几个可评测的原子任务。拿文档处理为例拆成抽取、摘要、改写、问答、格式转换。每个任务单独建集不做混合。第二步样本采集。优先从真实数据里采样比如历史对话、历史文档、线上日志。真实数据没有再用规则生成和人工构造补齐但规则生成的样本要控制重复度。第三步设计输入输出规范。每一条评测样本必须包含输入、期望输出、评测依据、难度标记、场景标签。没有期望输出的评测样本只配叫“交流素材”不配叫“测试题”。第四步多轮标注校验。至少两个人独立标注同一条样本不一致的进入仲裁流程而不是少数服从多数直接改掉。第五步分层管理。按功能模块、难度等级、业务场景打标签这样评测结束后可以按标签切片分析才知道模型到底在哪个环节掉链子。2.3 标注质量与多轮复核评测集的质量上限由标注质量决定。我踩过最大的坑是标注人员对“期望输出”的理解不一致。一个人觉得“答案正确即可”另一个人觉得“必须包含完整推理过程”结果同一道题在不同人手里标准完全不同评测失败案例根本没法定责。后来我强制要求每条样本的“评测依据”必须写明评分侧重比如“答案正确性占 60%推理过程完整性占 40%”并且做一轮试标注。试标注的样本刻意选边界情况让标注人员充分讨论把标准对齐后再正式标注。也可参考社区里常见的开源数据标注规范很多大模型团队都会公开自己的标注细则拿来改造比自己从头造要靠谱得多。2.4 防污染与数据新鲜度评测集一旦泄露评测就失去意义。所谓泄露不只是模型训练时见过原文还包括模型见过结构相似、表述相近的题目。我见过有人直接拿网上流传的“DeepSeek 数据标注样例”做评测集里面的题目早被各种开源模型翻来覆去训练过跑出来的分数根本没有区分度。防污染我一般做三件事新题留样每次评测留出 20% 不公开、不外传的自建新题只在内部环境里跑。表述变换同一道题准备多个表述版本随机抽一种生成最终评测输入。时间戳管理样本集按版本命名记录生成时间、来源、更新时间随时能追溯。另外评测集要有保鲜期业务变化快的话每两三个月就得更新一次。拿客服场景来说上半年商品政策下的用户问题年尾可能完全变了旧评测集测出来的分数再高也不能代表当下业务。2.5 鲁棒性与对抗样本测模型的下限常规评测测的是模型上限鲁棒性测试测的是模型下限。我会给每个核心评测集配一套对抗样本专门看模型在恶劣条件下的表现。对抗样本的做法不涉及攻击性内容就是把输入做正常的扰动比如加入错别字、口语省略、不完整语句。改变标点、大小写、换行格式。把问题换一种问法但语义完全一致。在上下文中塞入无关信息看模型会不会被带偏。这类样本不需要多每个任务 30 到 50 条就够但很能说明问题。模型上线后面对的输入永远不会像测试集那么干净鲁棒性测试可以直接预警风险。3. 自动化评测跑分很快但跑对很难自动评测是效率的保障但稍不注意就会变成数字游戏。我这里把主流的自动评测方式从头到尾讲清楚包括指标本质、适用边界以及大家常说的“用大模型评大模型”到底怎么落地。3.1 生成式文本指标BLEU、ROUGE、BertScore 与语义相似度对于摘要、翻译、生成的文本大家用得最多的是 BLEU 和 ROUGE。这两个指标本质是 n-gram 重叠度计算优点是快、稳定、可复现缺点是检测不出“意思对但用词不同”的情况。我拿摘要场景举例模型把“公司第三季度营收增长 20%”改写成“公司第三季营收较去年同期上升两成”字面重叠度低但语义完全正确。所以遇到这类生成任务我不会只依赖 BLEU/ROUGE而是叠加语义相似度计算用向量模型把参考答案和模型输出分别编码计算余弦相似度。需要提醒的是语义相似度分数高分未必等于真实质量高它只能告诉你“接近程度”不能告诉你“哪里好哪里坏”。所以语义指标适合做初筛不适合做终审。3.2 任务型指标准确率、Passk 与工具调用成功率如果评测目标是任务是否完成就需要更结构化的判定方式。数学题的最终答案匹配、代码题的可执行性判断、检索任务的相关性排序这些都可以用确定性指标。代码生成是我用得比较多的场景HumanEval 是最常用的集子核心看 Passk意思是让模型针对一道题生成 k 个答案只要有一个能跑通就算通过。Pass1 代表一次生成的准确率Pass100 反映模型的理论能力上限。这里有个坑k 越大测试成本越高而且在业务里 Pass100 没意义因为生产环境通常只让你生成一次。我一般重点看 Pass1Pass5 作为参考。工具调用也是近期的热点。无论是给 Agent 用的选工具、填参数还是简单的函数调用评测核心指标是工具选择准确率和参数填充正确率。这类评测最好写成自动化校验脚本把模型输出的函数名、参数名直接解析出来跟期望值比对。3.3 LLM-as-a-Judge 的写法与实践开放式问答、内容创作这类任务机器指标很难覆盖质量大家普遍转向让大模型当裁判。我在这方面的体会是用得好它是效率利器用得糙它就是“盲人骑瞎马”。核心问题在于必须先解决大模型评判的三个偏差。第一个是位置偏差裁判模型更喜欢第一个或者最后一个候选答案。第二个是长度偏差越长的回答越容易被打高分哪怕内容啰嗦。第三个是自我偏好偏差裁判模型倾向于给自己的同类模型打高分。应对方法我总结为三条把候选答案顺序随机打乱多次投票取结果。在 prompt 中强制裁判先列要点再给分并且限制字数范围。至少用两个不同模型做交叉裁判不一致的样本最终拿回人工。下面是我常用的一版评判 prompt 模板你可以直接拿去做初版你是一个严格的评测裁判。给你一个用户问题、两个候选回答以及一个评分标准。 请先逐条列出你对每个候选回答的分析是否相关、是否准确、是否完整、是否存在事实错误。 然后用 1 到 5 分分别评分1 分最差5 分最好。 注意评分要依据内容质量不要依据回答长度。最后输出 JSON 格式 {analysis: ..., score_a: 3, score_b: 4, reason: ...}用大模型当裁判不是完全客观的但它最大的价值是能覆盖成百上千条样本的初步筛选。我通常把自动裁判当成“漏斗”初筛后保留有争议的样本给人类评审效率和质量都能兼顾。3.4 主流通用评测工具链lm-evaluation-harness、OpenCompass 与 vLLM 结合工具方面我日常用得最多的是 EleutherAI 的 lm-evaluation-harness配合 vLLM 跑加速推理。OpenCompass开源评测平台也很好用尤其在中文场景和多模型对比上有不少内置任务。UltraEval 在一些垂类评测集上做得也不错。拿 lm-evaluation-harness 配 vLLM 的典型命令大概是这样的lm_eval --model vllm \ --model_args pretrainedQwen/Qwen2.5-7B-Instruct,tensor_parallel_size1,trust_remote_codeTrue \ --tasks mmlu,gsm8k \ --batch_size auto \ --output_path ./eval_results这里需要说明的是--tasks参数后面的任务名必须跟你的 har 版本匹配不同版本的任务名写法和注册方式有差异先跑lm_eval --task_list | grep mmlu确认一下再执行。另外如果你想对比多个模型一定保持同一套 prompt、同一个采样参数、同一个 seed。我见过太多对比报告因为 temperature 不一致跑出来的结果完全没法横向比较。4. 人工评测把模糊的“感觉”变成可追溯的“打分”自动评测能覆盖大多数标准化样本可一旦涉及原创性、逻辑连贯性、审美偏好这类主观维度机器指标就力不从心了。人工评测是绕不开的但人工评测不等于“找几个人看看答案给个印象分”。4.1 什么时候必须上人评我的判断标准很简单如果这个任务的结果要被真实用户直接消费且质量高度依赖主观感受就必须上人评。典型场景包括客服话术是否自然、有没有温度。营销文案是否符合品牌调性。复杂问题的回答是否逻辑严谨、结构清晰。对敏感话题的边界处理是否稳妥。这类任务里一个答案在自动指标上可能接近满分但人一看就能感觉到“不像真人写的”。还有一个高频场景是模型迭代后的回归有时候自动指标没有明显变化但人的体感就是“回复变敷衍了”。人工评测能捕捉到这种细微信号。4.2 维度、打分卡和校准会人工评测最忌讳没有标准。我一般把评分维度定成 58 个避免贪多比如相关性、准确性、完整性、逻辑连贯性、可读性、格式遵循、安全合规。每个维度单独出分不设综合分因为综合分容易掩盖偏科问题。打分卡也要具体到每个分数档位的行为描述。以“准确性”为例分数行为描述5 分答案所有关键事实正确无任何误导性信息4 分答案正确但有一处无伤大雅的遗漏或表述不完整3 分主要观点正确出现一处次要错误或明显误解2 分部分正确关键信息有误或偏离问题1 分基本错误或答非所问评分之前必须做一次校准会。拉上所有参与评分的人选 10 到 15 条典型样本大家同时评、同时现场讨论把标准真正对齐。我不止一次发现不同背景的评分者对于“5 分长什么样”的理解差异巨大不校准后面评分就是各说各话。4.3 盲评、交叉评分与一致性检查人工评测要做到可信必须盲评。把模型名、版本号全部隐藏甚至把两个模型的回答随机交换顺序防止先入为主。有条件的话做双盲评分者既不知道模型身份也不知道评测集的设计意图。交叉评分方面我的最低标准是每条有效样本至少两个人独立评分然后计算评分一致性。一致性可以用简单的 Cohens Kappa 来看首轮一般要求 0.6 以上低于这个值就说明评分标准还没对齐应该停下来再校准而不是硬着头皮继续评。这里分享一个具体教训我做过一轮大模型评测项目前 50 条样本的两名评分者一致性只有 0.45。当时觉得浪费时间强行把余下样本评完了。结果后面分析时发现大量失败样例的“失败原因”都判不到一起报告根本没法写。后来重新定标准、重新评反而比第一次快得多。4.4 人工评测过程中常见的心理偏差人评的偏差是真实存在的主要有几个。锚定效应评分者看了第一条高分答案后后面所有答案都会不自觉地跟它比。应对办法是先评分再排名最后再校准分数区间。疲劳效应连续评几十条后评分尺度会越来越松。所以单次评测算好最多评 50 条超过就分批次。首因效应同一个模型的答案第一条好后续印象会整体偏高。盲评加乱序能有效对冲。还有一些伪装客观的坑比如“对比式评分”比“单条评分”更容易引入偏差。所以我在需要精细判断时倾向让评分者先单条打分再做成对对比而不是一开始就给出相对排名。5. 部署环境、Agent 与多模态评测范围要跟着产品形态走评测如果只停留在“模型能不能答”那还没进入实战。真正上线之后你测的其实是“模型在这个系统里能不能稳定干活”。这一节重点说部署环境、Agent 场景和多模态下的评测差异。5.1 性能评测不能只看生成质量模型选型时除了看质量分还得看吞吐、延迟和资源占用。同一个模型用不同推理框架部署可用性差异很大。我遇到过的典型案例是某模型用原始 PyTorch 跑速度惨不忍睹但换了 vLLM 之后吞吐翻了快十倍而生成质量几乎不变。这说明性能评测必须贴着实际部署方式来做不能脱离环境谈。性能评测的核心指标一般有这么几个TTFT首 Token 时间用户发出请求到收到第一个 Token 的时间。直接影响响应体感。TPOT每个 Token 的输出时间影响长文本生成的流畅度。吞吐量单位时间能处理的请求数或 Token 数决定服务容量。并发稳定性在高峰并发下延迟会不会剧烈抖动、OOM。这些指标跟模型参数量、量化精度、上下文长度、显存大小直接相关。做过本地部署评测的朋友应该都清楚同一个模型 16 比特和 8 比特量化质量分能差多少显存占用和生成速度又能差多少。所以选型报告里的评测结果必须标注“模型版本 量化方式 推理框架 GPU 型号 并发数”缺一个参数这个结果就不可复现。另外一个注意点免费 API、云端 API、私有化部署三者的行为可能不一样。厂商的 API 通常会藏一些推理层优化跟你本地部署的产出不完全一致。如果项目最终是私有化部署那么评测也要在私有化环境里重新跑一遍不能直接拿 API 评测结果当生产依据。5.2 长上下文评测从大海捞针到真实文档任务长文本是评测里特别容易“注水”的领域。很多模型宣称支持几百 K 上下文实际你用一条中等长度的文档让它做细节问答它就开始丢信息了。业界常用“大海捞针”测试来测长上下文检索能力把一条关键信息埋在长文本的某个位置问模型一个只有埋点能回答的问题看它在不同上下文长度下的正确率。这类测试做筛选可以但我不建议作为终审因为它只测“能不能找到”不测“能不能综合理解”。更贴近实战的做法是构建一组长文档真实任务评测集比如从 50 页 PDF 中抽取指定字段并汇总。根据合同全文回答涉及多个章节的交叉问题。给定会议记录生成带行动项清单的摘要。长文本评测还要专门测位置敏感性。把关键信息分别放在文章开头、中间、结尾处各测一遍观察表现差异。很多模型对中段位置的利用能力明显弱于开头和结尾这类短板只有用位置敏感测试才能暴露。5.3 Agent 评测集怎么构建和使用Agent 是大模型应用的高频形态这时候评测的单位从“答案”变成“任务”。我身边的团队经常问 Agent 评测跟普通大模型评测有什么不一样核心差异在于你不仅要看最终结果还要看中间步骤。Agent 评测集的构建推荐按这四层来设计第一层是原子能力层工具选择对不对、参数填得准不准、单步指令理解对不对。这是 Agent 能干活的基础。第二层是任务完成层给定一个完整任务Agent 能否在不借助人干预的条件下完成。判定标准可以是最终产物的可执行性、正确率或者是关键目标的达成情况。第三层是多步路径层把任务拆成多步检测 Agent 每一步是否走了最优路径、有没有无效循环、有没有出现幻觉工具调用。这里通常会在评测集里标注参考步骤序列但不强制要求完全一致同时也允许等价路径存在。第四层是恢复能力层给 Agent 构造一些失败场景比如工具返回错误、API 超时看它能否自己识别错误并调整策略而不是直接崩掉。Agent 评测集里的成功判定必须做到“可自动执行”否则人工跟踪成本极高。比如工具调用评测用脚本模拟工具环境检查 Agent 的调用序列是否符合预期。5.4 多模态评测的注意点多模态大模型的评测比纯文本更复杂因为它涉及图像、音频、视频等多种输入且评测标准容易模糊。常见的评测任务包括图片内容描述、OCR 抽取、图表理解、视觉问答、跨模态推理。“图上是什么”这类简单任务准确率指标没问题但一旦涉及空间关系、推理、计数生成的答案就要结构化再交给脚本或裁判模型判断。多模态评测集构建时我额外注意三类样本一是混合文本与视觉信息的样本比如“图里这张海报上的活动日期是什么”二是需要跨模态推理的样本比如“根据表格和柱状图判断趋势是否一致”三是低质量输入样本比如模糊截图、倾斜文档、反光照片。现实中这类低质量输入的比例远比想象中高评测时不覆盖上线后就会被打得措手不及。6. 评测报告之外让评测进入模型迭代的循环评测做完形成了结论工作就结束了吗对很多团队来说确实结束了但真正发挥评测价值的地方恰恰是它之后的循环。6.1 一份能复现的评测报告长什么样我会在评测报告里强制包含“可复现信息”章节模型名称及版本、评测集文件名和版本号、Prompt 模板全文、采样参数temperature、top_p、seed、推理框架与部署环境、GPU 型号、评测时间。没有这些三个月后你自己都复现不了当时的结果。报告正文不要只放一张分数表。我一般还会给三个东西分能力项得分、典型示例、失败案例分析。典型示例要选有代表性的一半放好的一半放差的。差的示例尤其重要因为决策者需要通过具体案例来感受模型的实际水平。6.2 错误聚类是比分数更重要的产出跑完一轮评测我做的第一件事从来不是看平均分而是把失败样本捞出来做错误聚类。错误类型大致可以分成几类理解偏差模型没读懂问题答非所问。知识缺失问题涉及的知识不在训练范围内。指令遵循不足模型理解了但没按格式或约束执行。推理链条断裂结论对中间过程错误。幻觉信息凭空捏造事实。格式混乱输出结构不符合要求。每类错误统计数量和占比然后去看哪一类占比最高。如果是推理链条断裂多那评测集的难度设计可能就有问题如果指令遵循不足多那可能是 prompt 模板和模型对齐度不够。错误聚类能直接指出下一步该往哪个方向去补数据、调 prompt 还是换模型。6.3 评测驱动的微调循环评测的最终价值要落在模型迭代上。我建议把评测集当回归测试来用而不是当一次性的评分工具。微调循环可以这样跑第一步用评测集跑出基线分数和错误分布。第二步对错误样本做人工分析筛选出值得“教会模型”的典型失败原因。第三步围绕这些失败原因构造训练数据设计针对性的 指令样本比如把格式要求写进系统提示、补充推理链数据。第四步微调后立刻回到同一套评测集做回归。第五步重点检查原本的错误类别是否下降同时警惕其他能力是否退化。这里有一个非常关键的坑回归测试集不能只用“旧题”。如果只用旧题回归模型可能直接死记硬背答案短期分数涨了真实能力没变。我一般会做“旧题新题混合回归”旧题看稳定性新题看泛化性。6.4 给评测结果“存档”的习惯最后说一点我一直坚持的做法也算是我送你的一个建议。每次评测跑完除了分数表我会把所有输入输出原样存档按模型版本、测试集版本、推理参数、时间戳命名绝不改动。这个习惯救过我太多次比如某次模型版本更新后线上反馈变差靠对比存档输出才定位到是 prompt 模板中的微小改动引发的问题某个新模型分数看着不错一翻存档才发现同类 old bad case 全部复发。大模型评测的目的从来不是让模型考高分而是让模型在你已知的边界内被信任。先把可能出问题的地方测明白上线以后才不会被意外砸中。把这个环节做成固定的基础设施而不是偶发的临时行为你的模型选型和迭代才会有真正的底气。