1. 为什么“AI性能测评参考”这件事越来越难做1.1 测评对象从“几个模型”变成了“一整条链路”两年前聊AI性能测评大家默认说的是“拿几个大模型跑同一套题看谁分高”。现在完全不是这么回事了。你随便打开一个AI应用背后可能是一个路由层挂着三四个不同厂商的模型中间夹着提示词模板、检索增强、工具调用、缓存策略最后才吐出一个回答。这时候你说“这个AI好用”到底是在夸底层模型还是在夸那套工程封装我自己从2023年开始断断续续做模型对比测试最开始用Excel记分数就够了现在得写脚本、搭评测集、跑多轮回归。测评的复杂度涨了不止一个量级。所以这篇内容我想把“AI性能测评参考”这件事拆开讲——不是给你一个排行榜而是给你一套自己动手做测评的思路和工具链。适合谁看如果你是需要选型的技术负责人、正在做AI应用开发的工程师、或者单纯想搞清楚“哪个模型适合我”的重度用户接下来的内容应该都能用上。1.2 测评的核心矛盾标准化与场景化之间的拉扯所有做AI测评的人都会撞上同一个问题标准化的评测集比如MMLU、HumanEval这些分数高不代表你的实际场景里就好用。反过来你拿自己的业务数据测出来的结果又很难跟别人的数据横向对比。我的处理方式是“两层测评”第一层用公开基准做粗筛把明显不行的模型淘汰掉第二层用自建场景集做精测这一层才是决定选谁的关键。两层之间的权重怎么分配取决于你的场景有多特殊。如果是通用问答公开基准的参考价值能占六成如果是垂直领域的专业任务自建集的权重至少要占到八成。这个思路听起来简单但实操中有很多细节会决定测评结果是否可信。下面我按“设计测评方案—搭建测评环境—执行测评—分析结果”这条线把每个环节的关键点都过一遍。2. 测评方案设计先想清楚你要测什么2.1 明确测评维度别只看“准不准”很多人做AI测评只盯着准确率这是最大的误区。一个模型的性能至少要从五个维度去看准确性回答是否正确、是否切题。这是基础但远远不够。稳定性同一个问题问十次答案是否一致。有些模型每次回答都不一样在需要确定性输出的场景里这是致命的。响应速度首token延迟和完整响应时间。流式输出场景下首token延迟比总时间更影响体验。成本按token计费的话同样任务下不同模型的成本可能差十几倍。安全性是否会输出有害内容、是否会泄露系统提示词、是否会被提示注入攻击。这五个维度里准确性和安全性需要构造专门的测试用例稳定性和响应速度可以通过自动化脚本批量测成本则需要结合你的实际调用量来算。我一般会做一个加权评分表权重根据业务场景调整。比如做实时客服响应速度的权重会拉到30%以上做离线内容生成速度就没那么重要准确性和成本的权重更高。2.2 构建评测集公开基准自建场景集公开基准的好处是省事、可对比。常用的有基准名称侧重方向适用场景MMLU多学科知识通用知识问答HumanEval代码生成编程辅助GSM8K数学推理逻辑计算C-Eval中文知识中文场景MT-Bench多轮对话聊天机器人但公开基准有个大问题数据污染。很多模型在训练时已经见过这些题目了分数虚高。所以我更看重自建场景集。自建场景集的构建流程是这样的从你的实际业务里抽取200-500个真实问题覆盖主要任务类型每个问题标注标准答案或评分标准。如果人力不够可以用强模型生成候选答案再人工审核。关键是评测集不能泄露到训练数据里否则测了等于没测。注意自建评测集要定期更新。模型在迭代你的业务也在变化半年前的评测集可能已经不能反映当前的真实需求了。我一般每季度会替换掉20%左右的题目。2.3 评分方式的选择人工、模型裁判、还是规则匹配评分方式直接决定了测评的成本和可信度。三种方式各有适用场景规则匹配适合有明确答案的任务比如数学题、代码题、分类任务。写个脚本自动比对就行成本最低但只能用于答案确定的情况。模型裁判是用一个强模型来给另一个模型的输出打分。这种方式适合开放式问答成本比人工低很多但要注意裁判模型本身的偏见——它可能偏好跟自己风格相似的输出。我的做法是用两个不同厂商的模型做裁判取平均分减少单一偏见。人工评分是最可靠的但成本最高。我一般只在关键决策点上用人工比如最终选型阶段对Top 3模型做精细对比。人工评分时要用统一的评分量表否则不同人的标准不一致结果没法比。3. 测评环境搭建让结果可复现3.1 本地部署 vs API调用怎么选做测评时模型来源有两种本地部署和API调用。两者各有优劣选择取决于你的测评目标。本地部署的好处是可控性强——你可以固定模型版本、调整推理参数、不受网络波动影响。坏处是硬件成本高大参数模型需要多卡才能跑起来。如果只是做小规模测评用消费级显卡跑7B到14B的模型是可行的量化后显存占用能压到8-16GB。API调用的好处是省事能测到最新的闭源模型。坏处是版本可能随时更新今天测的结果明天就复现不了。我的做法是对闭源模型测评时记录调用日期和返回的模型版本号对开源模型固定commit hash和量化方式。3.2 推理参数固定温度、top_p、max_tokens测评结果不可复现十有八九是因为推理参数没固定。温度temperature影响输出的随机性top_p影响采样范围max_tokens影响输出长度。这三个参数不固定同一个模型同一道题每次跑出来的结果都可能不一样。我的标准配置是温度设为0或0.1需要确定性输出时用0top_p设为1max_tokens根据任务类型设定问答类512代码类1024长文生成2048。所有模型用同一套参数这样对比才公平。有些模型不支持温度设为0那就统一设为0.01尽量接近确定性输出。另外要注意即使温度设为0由于浮点计算的精度问题不同硬件上跑出来的结果也可能有微小差异这是正常的。3.3 自动化测评脚本的基本框架手工一个个测效率太低必须写脚本。我用Python写了一个测评框架核心逻辑不复杂import time import json from openai import OpenAI client OpenAI(base_url你的API地址, api_key你的密钥) def evaluate(model_name, test_cases, temperature0.1, max_tokens512): results [] for case in test_cases: start time.time() response client.chat.completions.create( modelmodel_name, messages[{role: user, content: case[question]}], temperaturetemperature, max_tokensmax_tokens ) elapsed time.time() - start results.append({ question: case[question], expected: case.get(expected, ), answer: response.choices[0].message.content, latency: round(elapsed, 2), tokens: response.usage.total_tokens if response.usage else 0 }) return results这个框架可以扩展加并发请求测吞吐量加多轮对话测上下文保持能力加异常输入测鲁棒性。关键是把结果存成结构化数据JSON或CSV方便后续分析。提示跑批量测评时注意API的速率限制。我一般用信号量控制并发数避免触发限流导致测评中断。另外要加重试逻辑网络抖动时自动重试否则会丢数据。4. 核心测评环节的实操细节4.1 准确性测评怎么出题才有区分度出题是门手艺。太简单的题所有模型都能答对没有区分度太难的题所有模型都答错也没有区分度。好的评测集应该呈正态分布——大部分题中等难度少数简单和少数困难。我出题时会遵循几个原则第一避免训练数据里常见的题目比如“中国的首都是哪里”这种模型肯定见过第二同一知识点用不同问法出多道题测模型的泛化能力第三加入干扰项比如在问题里混入无关信息看模型能否抓住重点。举个例子测数学推理时不要只出“35等于几”要出“小明有3个苹果又买了5个给了小红2个还剩几个”。后者需要多步推理更能区分模型能力。再进一步可以把数字换成不常见的比如“小明有137个苹果又买了289个”看模型在数值较大时是否还能算对。4.2 稳定性测评同一问题问十次稳定性测评的方法很直接同一个问题用同样的参数连续问N次我一般用10次看答案的一致程度。一致性的衡量方式有两种如果答案是确定性的比如数字、选项直接比对是否完全相同如果是开放式的用语义相似度或模型裁判来判断。实测下来温度设为0时大部分模型的稳定性都不错10次里能有9次以上一致。但有些模型即使温度设为0输出也会有波动这通常是因为推理框架的批处理策略导致的。如果你的场景对稳定性要求极高建议在应用层加缓存——相同问题直接返回缓存结果既稳定又省钱。4.3 速度测评首token延迟比总时间更重要速度测评要分两个指标首token延迟TTFT和总响应时间。在流式输出的场景下用户感知到的是首token延迟——只要第一个字出来了用户就觉得“它在响应了”。总响应时间影响的是完整答案的等待时长。测首token延迟需要流式接口。用流式调用时记录从发送请求到收到第一个chunk的时间。这个指标受网络影响很大建议在同一个网络环境下测所有模型并且多测几次取中位数。我实测的经验是同一梯队的模型首token延迟差距可能在200ms到1s之间。对于实时对话场景超过1.5s的首token延迟用户就能明显感觉到卡顿。所以如果做实时应用速度这个维度的权重要给足。4.4 成本测评别只看单价要看“完成任务的总成本”成本不能只看每百万token的单价。有些模型单价低但完成同一个任务需要的token多因为啰嗦或者需要多轮总成本反而更高。正确的算法是用你的评测集跑一遍统计每个模型完成所有任务的总token消耗再乘以单价。我做过一个对比模型A单价是模型B的一半但完成同样的代码生成任务模型A平均输出长度是模型B的1.8倍算下来总成本只便宜了10%左右。如果再考虑模型A需要更多轮修正才能达到可用状态实际成本可能还更高。所以成本测评一定要结合准确性一起看。我一般会算一个“有效成本”——只统计那些回答正确的任务的token消耗错误回答的token算浪费。这样算出来的成本才反映真实性价比。5. 测评结果分析与常见陷阱5.1 分数之外错误模式分析更有价值测评做完不要只看总分。把错误案例拉出来逐个分析往往能发现更有价值的信息。比如模型是在哪类问题上出错是理解错了题意还是知识缺失还是推理链条断了不同模型的错误模式不一样这直接关系到你在应用层怎么补。我测过两个总分接近的模型A模型在事实性问题上错得多B模型在推理题上错得多。如果你的场景是知识问答选A就不如选B如果是数学辅导那反过来。所以错误模式分析比总分更能指导选型。5.2 常见陷阱一评测集泄露这是最隐蔽的陷阱。如果你用的公开评测集在模型训练时已经被见过分数会虚高。判断方法是看模型在评测集上的表现是否显著高于在类似但更新的评测集上的表现。如果差距很大大概率有泄露。自建评测集也要注意不要把评测集的内容以任何形式放到网上包括GitHub、博客、论坛。一旦被爬虫抓走进了训练数据这个评测集就废了。5.3 常见陷阱二裁判模型的偏见用模型做裁判时裁判模型会偏好某些风格的输出。比如GPT-4做裁判时可能给结构清晰、分点作答的回答更高分即使内容深度不如另一个回答。这种偏见会导致测评结果偏离真实质量。缓解方法是用多个不同厂商的裁判模型取平均分或者在裁判提示词里明确评分标准减少主观性。更好的做法是定期用人工评分校准模型裁判的结果看看两者的相关性有多高。5.4 常见陷阱三忽略版本变化API模型的版本可能随时更新今天测的GPT-4和下周测的GPT-4可能不是同一个东西。开源模型虽然版本固定但如果你换了量化方式或推理框架结果也会变。我的做法是每次测评都记录完整的版本信息包括模型名称、版本号、调用日期、推理参数、量化方式如果是本地部署。这样即使结果有变化也能追溯到原因。6. 常见问题速查与避坑清单6.1 测评执行中的典型问题问题现象可能原因排查方向同一模型两次结果差异大温度未固定或API版本变化检查temperature参数记录模型版本首token延迟波动大网络抖动或服务端负载多测几次取中位数固定网络环境模型拒绝回答某些问题安全策略触发检查问题是否涉及敏感内容调整问法输出被截断max_tokens设置过小增大max_tokens或检查是否有长度限制成本远超预期输出啰嗦或需要多轮统计实际token消耗优化提示词6.2 我踩过的几个坑第一个坑早期做测评时没固定温度同一个模型跑两次结果差很多白白浪费了一周时间。后来所有测评都强制固定参数结果才稳定下来。第二个坑用公开评测集测一个刚发布的模型分数高得离谱后来发现那个评测集在训练数据里。从那以后我以自建集为主公开集只做参考。第三个坑只测了准确性选了一个准确率最高的模型上线结果响应太慢用户投诉。后来把速度权重加上重新选型才解决问题。6.3 给不同场景的测评建议实时对话场景速度权重30%稳定性25%准确性25%成本10%安全性10%离线内容生成准确性40%成本25%稳定性20%速度5%安全性10%代码辅助场景准确性45%稳定性20%速度15%成本10%安全性10%知识问答场景准确性40%安全性25%稳定性15%速度10%成本10%这些权重不是固定的根据你的实际业务调整。关键是在测评开始前就把权重定好不要等结果出来了再改权重那样容易自欺欺人。7. 测评之外持续监控与迭代7.1 上线不是终点而是监控的起点选型测评做完、模型上线之后测评工作其实才完成了一半。线上环境的真实表现可能和测评结果有偏差因为用户的实际输入比评测集更多样、更不可预测。我一般会在应用层加监控记录每次调用的输入输出、延迟、token消耗、用户反馈点赞/点踩。这些数据积累一段时间后可以反过来优化评测集——把线上高频问题补充进去把已经不再出现的问题移除。7.2 定期回归测评模型提供方会更新版本你的业务需求也会变化。我建议至少每季度做一次回归测评用同一套评测集测当前使用的模型和候选模型看看是否有更好的选择。回归测评不需要像初次选型那么全面可以只测核心场景的几十道题快速判断是否有必要做更深入的对比。如果发现当前模型的表现下降可能是因为版本更新或者候选模型有明显提升再启动完整测评。7.3 多模型路由不选一个而是组合使用实测下来没有哪个模型在所有场景下都是最优的。所以我现在更倾向于多模型路由简单问题用便宜快的模型复杂问题用贵但准的模型代码问题用代码专精的模型。路由策略可以基于规则比如按问题长度、关键词分类也可以用一个轻量模型做意图识别。这样组合下来整体成本和效果往往比单用一个模型更好。当然路由层本身也需要测评——路由的准确性直接影响最终体验。8. 一些个人体会做AI性能测评这件事工具和脚本只是辅助核心还是想清楚你要什么。我见过太多人花大量时间跑分最后选了一个“跑分最高”的模型上线后发现根本不适合自己的场景。问题就出在测评之前没想清楚业务需求。另外测评结果永远只是参考不是真理。模型在评测集上的表现和在实际场景中的表现之间永远有一道鸿沟。缩小这道鸿沟的唯一办法就是让评测集尽可能贴近真实场景并且在线上持续监控和迭代。最后分享一个实用技巧如果你刚开始做测评不要一上来就搞大而全的框架。先用Excel手工测20道题把流程跑通找到感觉之后再写脚本自动化。我见过有人花两周搭测评框架结果框架搭好了测评的兴致也没了。先跑起来再优化这个顺序不能反。
