1. 为什么“跑个分”这件事越来越不靠谱了这两年我经手过的大模型选型项目少说也有十几个从最早的“哪个模型能跑通就行”到后来要对比推理延迟、上下文吞吐、工具调用准确率再到最近半年开始有人问我“同一个模型在不同云厂商那里跑出来的效果为什么不一样”。说实话AI性能测评这件事已经从当年跑个MMLU、HumanEval就能交差的阶段彻底变成了一个需要工程化思维的活儿。我写这篇东西的起因很简单上个月帮一个团队做模型选型他们拿了一份网上流传的“大模型排行榜”来找我说想按那个榜单采购。我打开一看榜单上排第一的模型在他们实际业务场景里跑出来的准确率排到了第七。问题出在哪出在那个榜单测的是通用知识问答而他们的业务是结构化信息抽取加长文档理解。测评维度和业务场景错配分数再高也是白搭。所以这篇内容我想聊的不是“哪个模型最强”而是怎么建立一套属于你自己的AI性能测评参考体系。这套东西适合谁看如果你是AI应用开发者、技术选型负责人、或者正在做AI产品落地的工程师那接下来的内容应该能帮你少走不少弯路。如果你只是想知道“现在哪个AI好用”那这篇可能对你来说偏工程了一些但里面的思路你同样可以拿去判断那些排行榜靠不靠谱。核心关键词就两个AI和性能测评。但我要做的不是给你一个现成的榜单而是给你一套可以自己动手、反复使用的测评方法论。榜单会过时方法论不会。2. 测评体系到底该怎么搭从“跑分思维”切换到“场景思维”2.1 先搞清楚你要测的到底是什么很多人一上来就问“哪个模型跑分高”这个问题本身就问错了。你应该问的是“在我的场景下哪个模型的综合表现最好”。这两者的区别就像问“哪个运动员最厉害”和“哪个运动员最适合打前锋”一样。我一般会把测评维度拆成四层基础能力层语言理解、逻辑推理、知识覆盖。这一层是模型的“底子”决定了它能做什么。任务执行层指令遵循、格式输出、工具调用、多轮对话保持。这一层决定了它能不能按你的要求干活。工程性能层首token延迟、输出吞吐、并发承载、上下文窗口实际可用长度。这一层决定了它能不能在生产环境跑起来。成本层每百万token的输入输出价格、缓存命中率、批处理折扣。这一层决定了你的商业模式能不能成立。这四层缺一不可。我见过太多团队只测第一层结果模型选出来发现延迟高得没法做实时交互或者成本算下来根本覆盖不了毛利。2.2 为什么通用榜单只能当参考不能当依据市面上那些通用榜单比如各种“大模型竞技场”或者学术基准测试它们的设计目标是区分模型的基础能力差异而不是预测模型在你业务上的表现。这两件事之间有巨大的鸿沟。我举个具体的例子。某个在MMLU上得分很高的模型在我做合同条款抽取的任务里F1值比另一个MMLU得分低5个点的模型还差。原因很简单MMLU考的是选择题而合同抽取需要的是长文本定位加结构化输出这两个能力之间没有强相关性。还有一个更隐蔽的问题数据污染。很多公开基准测试的题目已经在训练数据里出现过了模型可能只是“背过答案”而不是“真的会做”。你拿这种分数去做选型等于拿作弊的成绩单去招人。所以我的做法是通用榜单只看两个东西一是模型的基础能力下限如果连通用测试都拉胯那肯定不能用二是社区口碑大家实际用下来有没有反复提到的问题。真正的决策依据必须来自你自己构造的业务测评集。2.3 自建测评集的最小可行方案说到自建测评集很多人第一反应是“那得多少人力标注啊”。其实不需要。我一般用“三步走”的方式两三天就能搭出一个可用的测评集。第一步从真实业务日志里采样。把你过去一个月实际用户请求里最有代表性的200到500条拿出来去掉敏感信息作为原始素材。这些请求天然覆盖了你的真实分布比任何人工构造的测试集都准。第二步构造标准答案。对于有确定答案的任务比如信息抽取、分类人工标注一遍。对于开放式任务比如文案生成、对话不需要标准答案而是定义一套评分标准比如“是否包含关键信息点”“语气是否符合品牌调性”“有没有事实性错误”。第三步设计评分机制。能自动评分的用自动评分比如精确匹配、F1、BLEU、ROUGE不能自动评分的用LLM-as-Judge加人工抽检。这里有个坑用LLM做评委的时候评委模型的能力必须显著高于被评模型否则评出来的结果不可信。我一般会用当前最强的模型来做评委同时人工抽检10%的样本做校准。这套方案跑下来一个模型的完整测评大概需要半天到一天的时间。如果你要对比五六个模型一周之内能出结论。3. 核心测评维度拆解每个指标背后的门道3.1 基础能力测评别被“刷榜”迷惑基础能力测评里我重点关注三个指标推理链完整性、知识时效性、多语言一致性。推理链完整性不是看模型能不能给出正确答案而是看它的推理过程是否逻辑自洽。我常用的方法是给一道需要多步推理的题目然后检查中间步骤有没有跳步或者逻辑断裂。有些模型答案对了但过程是错的这种在简单任务上看不出来一旦任务复杂度上去就会暴露。知识时效性这个点经常被忽略。模型的训练数据有截止日期但很多业务场景需要的是最新信息。我的做法是构造一组“时效性敏感”的测试题比如“某公司上个月发布的财报里营收是多少”然后看模型是直接说“我不知道”还是编一个答案。诚实地说不知道的模型比编答案的模型更值得信任因为前者你可以通过RAG补上后者你连它什么时候在编都不知道。多语言一致性主要针对有出海需求的团队。同一个问题用中文、英文、日文分别问看回答质量是否一致。我测过不少模型中文很好但英文明显降智或者反过来。如果你的业务涉及多语言这个指标必须单独测。3.2 任务执行测评指令遵循是分水岭任务执行层是我花时间最多的地方因为这一层直接决定模型能不能“干活”。指令遵循的测试方法很简单给一组带有多重约束的指令看模型能不能全部满足。比如“用JSON格式输出包含name和age两个字段age必须是整数如果信息缺失则填null”。这种测试能快速筛掉一批“看起来聪明但不好用”的模型。格式输出的稳定性是另一个关键点。我遇到过模型在简单情况下能输出合法JSON但一旦输入变长或者包含特殊字符就开始输出带markdown代码块的“伪JSON”。这种在生产环境里是灾难性的因为你的解析器会直接崩掉。测试的时候一定要用边界case去压比如超长输入、特殊字符、嵌套结构。工具调用是现在AI Agent场景的核心能力。我测评的时候会构造一组需要调用外部工具的task比如“查一下今天北京的天气然后推荐穿什么衣服”看模型能不能正确识别需要调用天气API、正确构造参数、正确解析返回结果。这里有个细节很多模型在单轮工具调用上表现不错但多轮工具调用需要根据上一步结果决定下一步调什么就很容易乱。如果你的场景涉及复杂Agent这个必须重点测。多轮对话保持这个指标我一般用“信息回溯”的方式来测。在对话的第3轮埋一个信息点到第10轮的时候问一个需要用到那个信息点的问题看模型能不能正确回溯。实测下来大部分模型在5轮以内表现稳定超过10轮就开始出现信息丢失或者混淆。3.3 工程性能测评生产环境的硬门槛工程性能这一层很多做算法出身的人容易忽略但它恰恰是决定项目能不能上线的关键。首token延迟TTFT决定了用户感知的响应速度。对于实时交互场景TTFT超过2秒用户就会明显感到卡顿。我实测下来同一个模型在不同推理框架下TTFT能差3到5倍。比如用vLLM和用原生Transformers推理差距非常明显。输出吞吐TPS决定了长文本生成的体验。TPS低于20的时候用户看输出就像看人打字一样慢。TPS高于50的时候基本感觉是一瞬间出来的。并发承载这个指标必须压测才能知道。我一般用Locust或者wrk做压力测试从10并发开始逐步加到200并发观察P99延迟和错误率的变化曲线。很多模型在低并发下表现很好一到高并发就雪崩。上下文窗口实际可用长度是个大坑。官方说支持128K但你实际用的时候会发现超过32K之后模型对中间部分的信息召回率急剧下降。这个现象叫“lost in the middle”。我的测试方法是在长文档的不同位置埋入关键信息然后看模型能不能准确召回。实测下来大部分模型在窗口的前20%和后20%表现最好中间部分明显衰减。3.4 成本测评算清楚每一分钱成本这块不能只看API标价。我一般会算三个数单次请求平均成本把输入输出token数乘以单价再除以缓存命中率修正。单用户月成本根据用户平均使用频次和每次的token消耗来估算。规模化后的边际成本考虑批处理折扣、预留实例折扣等因素。这里有个容易被忽略的点缓存命中率。很多云厂商对重复的输入前缀有缓存折扣如果你的应用有大量重复的系统提示词缓存命中率能到70%以上成本直接打三折。但如果你的输入每次都不一样那这个折扣就吃不到。选型的时候一定要问清楚缓存策略。4. 实操流程从零搭建一套可复用的测评流水线4.1 环境准备与工具选型我目前的测评流水线主要跑在一台带A100的服务器上但大部分环节在消费级显卡上也能跑。核心工具链是这样的推理框架vLLM用于本地模型的高吞吐推理Ollama用于快速原型验证。测评框架自己写的一套Python脚本基于OpenAI兼容接口可以同时对接本地模型和云端API。评分工具精确匹配用Python原生实现语义相似度用sentence-transformersLLM-as-Judge用GPT-4或Claude。压测工具Locust做并发测试自己写的脚本做延迟分布统计。可视化Streamlit搭一个简单的看板把测评结果用表格和图表展示出来。这套工具链的好处是统一接口。不管你是测本地部署的模型还是调云端API测评脚本不用改只需要改配置里的base_url和api_key。4.2 测评集构造的具体步骤我拿一个实际项目举例。假设你要做一个“合同关键信息抽取”的AI应用需要从合同文本里抽取甲方、乙方、金额、签署日期、违约条款这五个字段。第一步从历史合同库里随机抽300份合同去掉敏感信息作为原始素材。第二步人工标注这300份合同的标准答案。标注的时候要注意边界case比如金额有大小写不一致的、日期格式不统一的、违约条款有多个子条款的。这些边界case才是区分模型好坏的关键。第三步把测评集分成三份开发集100份用来调试prompt、验证集100份用来选模型、测试集100份用来最终评估。三份数据不能有重叠。第四步定义评分标准。对于抽取任务我用的是字段级F1每个字段单独算精确率和召回率然后取平均。这样能看出模型是整体不行还是某个字段特别弱。4.3 测评执行与结果记录执行测评的时候我一般会跑三轮取平均避免单次波动。每轮之间清空对话历史确保独立性。记录的结果包括指标说明记录方式字段级F1每个字段的抽取准确率表格按字段分行格式合规率输出合法JSON的比例百分比首token延迟从请求发出到第一个token返回P50/P95/P99输出吞吐每秒生成的token数平均值单次成本输入输出token数乘以单价美元/千次这些数据跑完之后我会做一个加权综合评分。权重的分配取决于业务场景如果是对实时性要求高的场景延迟权重调高如果是对准确率要求高的场景F1权重调高。没有通用的权重只有适合你场景的权重。4.4 结果解读与选型决策拿到测评结果之后不要只看总分。我一般会做维度拆解和错误分析。维度拆解是把每个模型的强项和弱项列出来。比如模型A在金额抽取上F1是0.95但在违约条款上只有0.72模型B在金额上是0.88但在违约条款上是0.85。如果你的业务里违约条款更重要那模型B可能是更好的选择。错误分析是看模型犯的是什么类型的错误。是格式错误输出不是合法JSON是定位错误找错了段落还是理解错误把甲乙方搞反了不同类型的错误对应不同的修复成本。格式错误可以通过prompt工程解决理解错误可能就需要换模型了。我一般会输出一个决策矩阵把每个模型在每个维度上的表现列出来然后根据业务优先级做加权。最后选出来的往往不是总分最高的那个而是最匹配业务需求的那个。5. 常见问题与排查技巧实录5.1 为什么同一个模型在不同时间跑出来的分数不一样这是被问得最多的问题。原因通常有三个第一服务端负载波动。云端API在不同时间段的负载不一样高峰期延迟会明显升高甚至可能出现超时。我的做法是固定在同一时间段比如工作日上午10点做测评减少负载波动的影响。第二模型版本静默更新。很多云厂商会在不通知用户的情况下更新模型版本导致行为发生变化。我一般会在测评报告里记录模型的版本号或者快照日期方便后续对比。第三随机性。大模型生成本身有随机性temperature参数不为0的时候同一个输入两次输出可能不一样。我的做法是测评时把temperature设为0同时跑三轮取平均。5.2 测评集需要多大才够用这个问题没有标准答案但我的经验是100到500条是一个比较合理的范围。少于100条统计显著性不够分数波动大多于500条边际收益递减而且标注成本太高。如果你的任务特别复杂比如多轮Agent可能需要更多样本。但一般来说先把100条跑通看看区分度够不够不够再加。5.3 怎么判断一个模型的“真实能力”而不是“刷榜能力”我的方法是构造对抗性测试集。具体来说就是故意设计一些“陷阱题”在长文档的中间位置埋关键信息测试“lost in the middle”问题。给出相互矛盾的指令看模型会不会指出矛盾还是盲目执行。用不常见的表达方式提问看模型能不能正确理解意图。给出需要拒绝回答的请求看模型的安全对齐做得怎么样。这些陷阱题在公开榜单上是看不到的但恰恰能反映模型在真实场景下的鲁棒性。5.4 本地部署模型和云端API的测评差异本地部署模型和云端API的测评最大的差异在工程性能层。本地部署的延迟和吞吐取决于你的硬件配置和推理框架优化程度云端API则取决于厂商的基础设施。我一般会分开测本地部署重点测吞吐和并发因为这是你花钱买硬件换来的云端API重点测延迟稳定性和成本因为这是你按量付费买来的。还有一个差异是版本控制。本地部署你可以锁定模型版本云端API你只能祈祷厂商不静默更新。所以对于稳定性要求极高的场景我一般建议本地部署或者用厂商提供的版本锁定功能。5.5 测评频率应该多高我的建议是重大版本更新必测常规版本季度测业务场景变化时随时测。重大版本更新比如从GPT-4到GPT-4o必须重新跑一遍完整测评因为模型能力可能发生质变。常规版本更新比如小版本号变化可以只跑核心指标看看有没有明显退化。业务场景变化的时候比如从信息抽取扩展到对话生成那必须重新构造测评集。5.6 常见问题速查表问题现象可能原因排查方法解决思路分数波动大样本量不足或随机性增加样本量固定temperature跑三轮取平均格式错误率高prompt不够明确检查prompt里的格式约束加few-shot示例长文本召回差lost in the middle在不同位置埋信息测试分段处理或换模型延迟突然升高服务端负载或网络问题对比不同时间段的延迟错峰调用或换区域成本超预期缓存命中率低检查输入前缀重复率优化prompt结构多轮对话失忆上下文窗口不足测试不同轮次的信息回溯加摘要或换长窗口模型6. 一些踩坑之后的个人体会测评这件事最怕的就是“为了测评而测评”。我见过团队花了两周做了一套精美的测评报告结果选出来的模型上线之后问题一堆。回头一看测评集是从网上找的公开数据跟业务场景八竿子打不着。我的体会是测评集的质量比测评工具的质量重要十倍。你花三天时间从真实业务日志里采样构造的测评集比花三周时间调优的测评框架更有价值。因为前者直接反映业务需求后者只是工具。另一个体会是不要追求“全面”。我早期做测评的时候恨不得把能测的维度全测一遍结果报告写了五十页决策的时候还是不知道选哪个。后来我学乖了每次测评只聚焦三到五个核心指标其他指标作为参考。核心指标选对了决策就清晰了。最后一个体会测评是一个持续的过程不是一次性的任务。模型在更新业务在变化你的测评集和评分标准也需要跟着迭代。我现在的做法是每个季度review一次测评集把过时的case去掉把新出现的边界case加进去。这样测评结果才能持续反映真实情况。如果你刚开始做AI性能测评我的建议是从一个小场景切入先跑通“构造测评集-执行测评-分析结果-做决策”这个完整闭环然后再逐步扩展。不要一上来就搞大而全的体系那样很容易半途而废。先把一个场景做深做透后面的场景就可以复用这套方法论了。