说实话，这两年跟各种模型打交道多了，我越来越觉得“评测”这件事被低估了。很多人以为评测就是跑个分数、拉个榜单，看一眼排名就完事了。我一开始也这么想，直到自己在真实业务里踩了坑——榜单上分数漂亮的模型，上线之后各种掉链子，响应慢、答非所问、遇到边界情况直接崩掉。从那时候起我才认真去琢磨，模型综合评测到底是个什么东西，它值不值得花力气去做。
我的结论是值得，而且非常值得。模型综合评测，说白了就是在特定目标和场景下，用一套系统化的方法，把模型的能力、成本、风险这些维度全部摊开来看，给出一个有依据的判断。它不是单一指标的比拼，更不是一次性的考试。我把它理解成给模型做一次全面体检，效果好不好只是其中一项，鲁棒性、效率、安全性、业务收益都得看。它的价值也很直接——帮你在选型时不拍脑袋，帮你在迭代时知道往哪儿改，帮你在汇报时拿得出证据。应用场景就更广了，从算法团队内部做模型对比，到采购环节评估第三方API，再到上线前的准入门槛，都离不开它。
1.1 模型综合评测的定义、价值与应用场景
我见过不少团队做评测的方式特别朴素：找几十条样例，人工看一眼输出，觉得还行就过了。这种方式不能说是错的，但它只回答了“这个模型能不能用”，回答不了“它比另一个好在哪”“它在什么情况下会失效”“用它的代价是什么”。综合评测要解决的就是后面这些问题。
从我的实践来看，综合评测最核心的价值有三个。一是决策支撑，模型选型本质上是个多目标权衡问题，效果、延迟、成本、合规性往往互相拉扯，没有综合评测就只能凭感觉。二是风险前置，很多问题在离线评测阶段暴露出来，比上线后被动救火便宜太多。三是迭代导航，评测结果能告诉你模型在哪个维度是短板，优化方向一下子就清晰了。至于应用场景，我粗略分过几类：研发阶段的模型横向对比、上线前的准入评估、运行中的持续监控，还有采购和合规审查。每一类的侧重点不一样，但底层方法论是相通的。
1.2 综合评测的目标设定与维度框架
我特别想强调一点：评测目标没定清楚，后面全是白忙活。我吃过这个亏，团队花了两周跑完一堆指标，最后发现大家关心的根本不是这些。所以现在我做评测，第一步一定是把目标写下来，而且要写到能落地的那种程度，比如“在客服场景下，选出延迟低于800毫秒、意图识别准确率高于92%、且能通过安全审查的模型”，这种目标才有指导意义。
目标定完，维度框架就得跟上。我的习惯是把维度分成几层。效果层是基础，准确性、生成质量这些必须有。鲁棒层看模型稳不稳，换个数据分布、加点噪声还能不能扛住。效率层算经济账，延迟、吞吐、显存、成本。可信层管风险，公平性、安全性、隐私、可解释性。体验和业务层则回到人的感受和商业价值上。这几个层次不是并列关系，更像是一个漏斗，越往下越贴近真实落地。我个人觉得，很多评测失败就是因为只盯着效果层，把别的都忽略了。
1.3 评测设计原则：可复现、可比较、可解释与可追溯
这四个原则我几乎是逢人必讲，因为它们是评测可信度的地基。可复现说的是同一套评测，换个人、换个时间跑，结果得基本一致。要做到这点，数据集版本、评测脚本、环境配置、随机种子都得固定下来并且记录在案。我见过太多“跑完就找不到当时用的哪版数据”的情况，那种评测结果基本没有参考价值。
可比较和可解释是一对好搭档。可比较要求评测设计在不同模型之间保持公平，输入一样、评分标准一样、环境尽量一样。可解释则要求结果不能只给个数字，得说清楚这个分数是怎么来的、哪些样例拉低了分数、失败模式是什么。我自己做报告的时候，会专门留一页放bad case分析，这一页往往比总分更有用。可追溯稍微偏工程一点，指的是从原始数据到最终结论的每一步都能回查，谁改了什么、什么时候改的，都有记录。这四件事听起来有点繁琐，但它们决定了你的评测结论是“有说服力的证据”还是“看起来挺专业的猜测”。
1.4 从单项评测到综合评测的总体流程
我通常把整个流程拆成六步走。第一步是明确目标和场景，把业务需求翻译成可评测的问题。第二步是设计指标体系和权重，这一步需要和业务方对齐，不然很容易自嗨。第三步是准备数据集和测试集，包括常规集、边界集和对抗集，质量控制要在这时候做扎实。第四步是执行评测，单项评测先跑，把每个维度的原始结果拿到手。第五步是综合评分和结果解读，权重怎么设、分数怎么合、异常怎么处理，都要有明确规则。第六步是输出报告并进入决策或迭代环节。
这套流程里，我觉得最容易被低估的是第四步到第五步之间的过渡。单项评测跑完，你手里是一堆分散的数字，把它们合成一个有意义的结论，其实很考验判断力。我的做法是先看单项，再设权重，最后做敏感性分析——比如把某个权重调高调低，结论会不会翻盘。如果会翻盘，说明这个维度的不确定性很关键，得回头再确认。整个流程走下来，快的话一周，慢的话一个月，取决于场景复杂度和数据准备情况。但不管快慢，这套框架能保证你不漏掉关键环节，也不会在某个局部钻牛角尖出不来。
指标体系这事儿，我吃过两次亏才慢慢摸出门道。第一次是贪全，列了三十多个指标，跑完之后发现一半没人看，另一半互相打架。第二次是太窄，只盯准确率，结果模型上线第一天就被用户投诉回复太慢。后来我给自己定了个规矩：指标不在多，在于每个都有明确的决策含义。你看到这个数，能立刻知道该做什么，这个指标才算合格。
现在我用的是一个五层指标体系，效果、鲁棒与泛化、效率与资源、可信、体验与业务。这个分层不是学术上的严谨划分，更像是从我的实际经验里长出来的——越往下走，越贴近真实业务里那些“不出事但很要命”的问题。下面挨个说。
2.1 效果类指标：准确性、召回率、F1、任务完成率与生成质量
效果类指标是我最开始最熟的一类，也是最容易被误用的一类。准确率、召回率、F1这三个是老面孔了，分类任务里几乎绕不开。我通常的做法是先看混淆矩阵，再决定主看哪个。比如做内容审核，漏审的代价远大于误审，那我就会把召回率放在更高的位置，宁可牺牲一点准确率。这个取舍没有标准答案，得看业务场景能承受多大的错。
任务完成率是我后来才重视起来的指标。对生成式模型来说，单看BLEU、ROUGE这些字面匹配的分数意义有限，用户真正关心的是“这件事办完了没有”。我现在会设计一批带明确完成标准的任务，比如一段多轮对话之后用户的问题是否被解决、一条结构化输出的字段是否全部填对。这种指标比纯文本相似度更贴近真实体验，虽然标注成本高一些，但我觉得值。
生成质量这块，我一般拆成三个维度看：相关性、连贯性和信息量。相关性看回答有没有跑题，连贯性看段落之间读起来顺不顺，信息量看有没有实质内容还是车轱辘话。人工评估目前还是主力，但我也会用模型打分做辅助，两边对照着看，能把评分偏差压下来一些。有个小经验分享给大家，做人工评估的时候一定给标注员准备评分锚点，光说“1到5分”没有意义，得给出每一分的具体样例。
2.2 鲁棒与泛化类指标：分布外表现、对抗鲁棒性、稳定性与一致性
这一类指标是我最愿意花时间的地方，因为它决定了模型是“实验室里能打”还是“战场上能活”。分布外表现说白了就是换个数据分布还能不能行。我做过一个情感分析模型，训练集里全是标准书面语，拿去测社交媒体评论，准确率直接掉了一大截，模型完全看不懂网络用语和表情符号。这种问题在离线评测阶段不暴露出来，上线就是事故。
对抗鲁棒性的测试方式我一般分两手。一手是构造扰动样本，比如同义词替换、错别字注入、语序打乱，看输出会不会大幅变化；另一手是专门去找模型容易翻车的输入模式，比如长尾实体、否定句、多条件约束。我印象很深的一次，一个问答模型在“请用不超过10个字回答”这种约束下频繁违规，这其实就是指令遵循能力上的鲁棒性缺口。
稳定性和一致性这组指标容易被忽略，但我在实际项目里越来越看重它们。稳定性指的是同一个输入多次调用，输出是否保持在合理范围内；一致性指的是语义等价的输入，输出是否一致。我遇到过模型对“怎么退款”和“退款流程是什么”给出两套完全不同答案的情况，用户一对比就懵了。测试的时候我会准备一批等价问句对和重复调用样本，把输出差异量化出来。这类问题修起来不复杂，但不测就一定会踩。
2.3 效率与资源类指标：延迟、吞吐、显存占用、训练与推理成本
效率指标直接对应钱和体验，我是把它当一等公民看待的。延迟这块我会分P50、P90、P99三个分位看，只看平均值容易被长尾骗了。客服场景下P99延迟超过2秒用户体感就明显变差，哪怕平均只有800毫秒也没用。吞吐量则跟部署方式强相关，批处理场景和实时场景的衡量方式完全不一样，设计测试的时候要跟实际调用模式对齐。
显存占用和训练成本这两项在选型阶段很关键。我见过一个模型效果确实好，但单卡放不下，要上多卡并行，整体成本翻了三倍，最后业务方直接否了。训练成本还包括数据标注、微调迭代、实验试错的隐性投入，这些不写进评测报告里，决策者容易低估。我的习惯是做一张成本估算表，把硬件、人力、时间都折算进去，这样对比起来才有意义。
推理成本我通常按“每千次调用成本”来算，包含算力、带宽和第三方API费用。如果是自建服务，还要把运维人力和扩容弹性算进去。这块数字最好跟财务或运维同事一起核，算法同学自己估经常偏乐观。有次我按理论值算了个数，运维同事看完直接笑了，说实际负载波动大得多，峰值资源得按1.8倍预留。这种沟通很值，能让评测结论更站得住。
2.4 可信类指标：公平性、安全性、隐私保护、可解释性与合规性
可信类指标是那种“不出事没人提，出了事全找你”的类型。公平性我会按敏感属性分组做效果对比，比如不同性别、年龄段、地域的样本上准确率有没有明显差距。差距过大不一定是模型本身的问题，也可能是训练数据分布不均，但只要差距存在，就得记录下来并且在报告里标明。我一般会设一个容忍阈值，超过阈值就亮黄灯。
安全性涵盖的面比较广，我主要测三类：有害内容拒答率、提示注入防御能力、越狱攻击下的稳定性。有害内容这块要准备一套覆盖多风险类型的测试集，逐条看模型是拒绝、规避还是照做。提示注入是我近两年测得最多的一项，攻击方式更新很快，测试集也得跟着滚动更新，不然测了个寂寞。隐私保护主要看模型会不会在特定诱导下吐出训练数据里的敏感信息，这个测试要谨慎设计，别在测试过程中自己先泄露了。
可解释性和合规性是两块经常被放到最后的指标，我觉得挺可惜的。可解释性我主要看两点：模型能不能给出理由，理由和结论是否自洽。不是所有场景都需要强解释性，但金融、医疗这类领域绕不开。合规性则是硬门槛，数据来源是否合法、输出是否符合行业监管要求、有没有做必要的备案和审计，这些不过关，其他指标再漂亮也白搭。我现在的习惯是把合规检查放到评测流程的前置环节，早发现早处理。
2.5 体验与业务类指标：用户满意度、交互质量、业务收益与可维护性
体验类指标听起来有点虚，但我有一套相对落地的测法。用户满意度我会用两类数据交叉验证：一是显式的评分和反馈，二是隐式的行为指标，比如追问率、会话轮次、放弃率。追问率高不一定是坏事，可能说明用户愿意深入聊，但结合放弃率一起看就能分辨出是“聊得来”还是“没答到点上”。这组指标我一般会在小流量灰度环境里收集，比实验室里问“你觉得好不好”靠谱得多。
交互质量我关注的是响应节奏和表达风格。响应节奏包括首字延迟、流式输出的连贯感，表达风格包括语气是否合适、格式是否清晰、有没有冗余的客套话。这些细节单看都是小事，叠在一起就决定了用户愿不愿意继续用。我做过一个对比实验，同样的模型能力，只是把回复结构调得更清楚一点，用户满意度就上了一个台阶。
业务收益和维护性属于“算总账”层面的指标。业务收益可以是转化率、工单解决率、人工介入率这类能直接折算成钱的东西，也可以是效率提升这种间接收益。可维护性我一般看模型更新频率、回滚难度、监控覆盖度和故障恢复时间。一个模型效果再好，如果每次更新都要折腾两周、出了问题定位不到原因，长期看也是个负担。这组指标我建议在选型阶段就拉上业务方和运维一起看，别等到上线之后再补课。
工具这块我踩过的坑不比指标少。最早我拿一摞脚本硬拼评测流程，跑一个模型要手动改五六个配置文件，换来换去把自己换晕了。后来团队里来了个新同学，看完我的流程说了一句“这玩意儿没法人传人”，我才痛下决心重新选工具。选工具这件事，我的体会是先想清楚自己是什么规模的团队、跑多高频的评测，再去对工具，顺序反过来就容易掉进“功能很全但我用不上”的坑里。
3.1 评测工具选型维度：覆盖范围、任务适配、自动化程度与生态
覆盖范围是我最先看的一栏。有些工具只做分类和问答，有些能覆盖生成、多轮对话、代码、多模态。我现在的做法是把自己的评测任务清单列出来，对着工具的能力矩阵逐项勾，勾不上的那几项要评估是能靠插件补还是干脆换工具。覆盖面越全的工具，往往在单个任务上的深度会浅一点，这个取舍得提前想明白，别等跑了一半才发现某个关键任务测不了。
任务适配比覆盖范围更细。同样是文本生成评测，开放式创作和结构化抽取的评分方式完全不一样，工具支不支持自定义评分逻辑很关键。我会特意去看它能不能塞自己的评估函数、能不能接自建数据集、输出格式是不是我能直接消费的。曾经我用过一个平台，榜单很漂亮，但想加一个内部任务的评测得改它的源码，这就有点难受了。
自动化程度直接决定评测能不能常态化。手动触发的评测做一两次还行，做多了就变成负担。我关注的是三件事：能不能通过命令行或API一键发起、能不能接CI/CD在模型更新时自动跑、结果能不能自动归档和对比。生态这栏我看的是社区活跃度、文档质量和插件丰富度，一个工具再强，如果遇到问题搜不到答案、版本升级老破坏兼容，长期用下来也挺磨人。
3.2 通用评测框架与基准平台推荐
通用框架里我用得最多的是OpenCompass和lm-evaluation-harness这两套。OpenCompass是国内团队做的，中文任务覆盖得比较全，配置方式相对友好，适合需要中英文双语评测的团队。lm-evaluation-harness是EleutherAI出的，学术味重一些，基准测试的复现性好，跑公开榜单成绩的时候我一般用它。这两套我通常会同时装着，交叉验证一下结果，避免某一个框架的实现细节带来偏差。
基准平台方面，HELM是绕不开的一个。它把评测维度拉得很开，准确性、校准度、鲁棒性、公平性、效率都覆盖到了，适合做模型全景扫描。不过HELM跑起来资源消耗不小，小团队全量跑一次成本不低，我会挑其中跟自己场景最相关的几个场景子集来跑。另外一个我用得比较多的是C-Eval和CMMLU，这两个偏中文知识能力评测，做中文场景选型的时候能给出比较直观的参考。
我想提醒一点，公开榜单的分数只能当参考。榜单任务和你的真实业务之间隔着好几层，模型在榜单上排第一不代表在你场景里好用。我现在会把公开基准跑分作为初筛，筛掉明显不行的模型，剩下的候选一定要在自建评测集上再过一遍。这一步偷懒，后面选型翻车的概率很大。
3.3 专项评测工具：安全、鲁棒性、效率与可解释性评测
安全评测这块我主要用两类工具。一类是开源的安全测试集和框架，比如Giskard，它能对模型做系统性的偏见和有害性扫描，报告结构也比较清楚。另一类是提示注入和越狱测试工具，这类工具更新很快，我一般会自己维护一套测试用例，配合开源工具一起跑。安全评测有个特点，工具只能帮你覆盖已知的攻击模式，真正难防的是新出现的攻击手法，所以测试集得保持滚动更新。
鲁棒性评测我用TextAttack比较多。它对文本扰动的支持很全，同义词替换、字符级扰动、句式变换都能做，跑完能直接给出扰动前后的效果对比。效率评测我一般不用现成工具，PyTorch Profiler加上自己写的压测脚本更灵活，因为延迟和吞吐的测法跟部署架构强相关，通用工具很难完全适配。可解释性方面我用过SHAP和LIME，对结构化特征模型效果不错，对纯生成模型帮助有限，这块目前还没有特别顺手的工具，我更多是靠人工抽查加自建的一致性检查脚本。
专项工具的选择我有个原则：能自己写脚本搞定的，就不硬套工具。工具的价值在于帮你省重复劳动，不在于替你做判断。安全、鲁棒这类评测，判断标准往往跟业务强绑定，工具的默认配置经常不合用，自己写一层封装反而更省事。
3.4 工具组合策略与评测流水线搭建
我的工具组合思路是“一横一纵加一层胶水”。横向用OpenCompass或lm-evaluation-harness做通用能力扫描，纵向用专项工具在安全、鲁棒这些关键维度上深挖，胶水层是自己写的一套编排脚本，负责把数据集喂进去、把结果收回来、统一格式存下来。这层胶水看起来不起眼，但它决定了整个流水线是不是可维护。我现在这套胶水大概几百行Python，核心就做三件事：调度、归一化、对比。
流水线搭建上，我会把评测拆成触发、执行、归档、对比四段。触发可以手动也可以挂CI，执行阶段按任务类型分到不同的执行器，归档统一写进数据库或者对象存储，对比阶段自动生成跟上一版的差异报告。这套结构跑顺之后，模型更新带来的评测工作量能压掉一大半。我建议一开始别追求大而全，先把最核心的通用评测跑通，再一个一个把专项任务接进去，边用边补比一次性设计要靠谱。
还有个小经验，评测工具的输出格式一定要统一。不同工具吐出来的字段名、分值范围、样本粒度都不一样，如果不做归一化，后期做对比分析的时候光清洗数据就能耗掉半天。我在胶水层里专门写了转换模块，不管上游是什么工具，落到库里都是同一套结构。这个投入一次，后面每次评测都省心。
这一章是整套评测流程里最“落地”的部分。前面指标定得再漂亮、工具选得再顺手，如果评测数据集搭得糙、评分方法拍脑袋、报告写完没人看，整个体系就白转一圈。我在这块吃的亏最多，有一阵子评测做得很勤快，结果业务方一句“这个分数跟我实际感受对不上”就把我问住了。后来我才明白，评测要真正发挥作用，靠的是数据集扎实、评分透明、报告能翻译成决策语言，再挂上一个能持续转动的机制。
4.1 评测数据集与测试集构建及质量控制
数据集这件事我的教训是：公开数据集能帮你起步，但决定选型质量的永远是你的自建测试集。我最早直接拿几个公开榜单当评测的依据，跑出来的分数挺好看，模型上线后用户反馈却一塌糊涂。回头查原因，公开数据集和我们的真实输入分布差得太远，用户问的那种夹着缩写、错别字、方言口语的句子，榜单里压根没有。从那以后我把自建测试集当成一件正经工程来做，每次业务反馈badcase都往里面补，一年下来攒了几千条，覆盖的边角场景比任何公开集都全。
构建测试集我一般分三步走。第一步从线上日志和真实用户会话里采样，保证输入分布跟实际使用一致，采样的时候会刻意把长尾场景的权重放大一点，别让高频简单样本把难例淹掉。第二步做标注，标注规范要写清楚每个任务的判定标准，比如生成质量打分我会给出好中差的锚点样例，让标注同学保持一致。第三步做质检，我通常抽20%左右做双人交叉标注，一致性低于阈值的那批样本重新过一遍，标注质量不过关的测试集拿来评测等于给自己挖坑。
数据泄漏这关必须把住。训练集里混进测试样本，评测分数虚高，选型的时候会误判。我现在会在评测前跑一次近重复检测，用embedding相似度和n-gram重叠双管齐下，把跟训练数据过于接近的样本剔掉。另外测试集要版本化，每轮评测标注用的是哪个版本的数据集，报告里必须写清楚。有一次我们对比两个模型差了三个点，折腾半天才发现两次评测用的测试集版本不一样，这种低级错误一旦发生，前面所有分析都成了空中楼阁。
测试集还要定期更新。模型能力在涨，用户的问法也在变，一套测试集用两年就会老化，测不出新模型和新场景之间的差距。我现在的节奏是每个季度补一批新样本、退掉一批区分度已经饱和的旧样本，保持测试集的锐度。补样本的时候我优先从最近的线上badcase里挑，这些样本最能暴露候选模型的短板。
4.2 综合评分方法、权重设计与结果解读
综合评分最容易犯的错，是把一堆指标简单算个平均。不同维度的分数量纲不一样，有的看百分比，有的看毫秒，直接平均没有意义。我一般先做归一化，把每个指标折算到统一的分数区间，再按权重加权。归一化的基准点很关键，我会用当前线上主力模型作为锚点，把它的各维度表现定在60分左右，候选模型的分数相对它来算，这样出来的分值业务方一看就懂——80分就是明显强于现役模型。
权重设计这块我跟团队争论过很多次。技术同学喜欢给效果类指标高权重，业务同学更在意用户满意度和成本。我的做法是分场景定权重，客服问答场景把准确性和响应延迟权重拉高，创作辅助场景更看重生成质量和多样性，安全合规类的指标在哪个场景都不低于一个保底线。权重表我会写进评测配置里跟着版本走，避免每次评测都重新拍一遍。有一次我们的权重表被悄悄改过没记录，两个季度后的横向对比完全对不上，从那以后权重变更也走评审流程。
结果解读比算分本身更考验功力。我拿到综合分之后不会只看总分排名，一定会拆到维度去看。经常出现总分接近但短板完全不同的情况，A模型效果好但延迟高，B模型各项均衡但创新能力弱，选哪个取决于业务当下更痛的是什么。我还会看分数的置信区间，样本量小的维度分数波动大，不能拿小数点后两位的差异说事。评测报告里我现在会专门加一段“不确定性说明”，把哪些结论稳、哪些结论需要更多样本验证写清楚，省得业务方拿着一个偶然的排名做决策。
还有个习惯我觉得挺有用：给每个候选模型贴一个“能力画像”。把六七个核心维度的得分画成雷达图，谁的形状更贴近业务需求一目了然。沟通的时候拿图说话，比甩一张分数表格效率高得多。
4.3 评测报告输出、模型选型与迭代优化闭环
评测报告我踩过一个很典型的坑：第一版报告写成了指标大杂烩，二十多页，业务方翻了两页就放下了。后来我改了写法，开头先给一页结论摘要，候选模型排名、推荐选型和关键风险三件事写清楚，后面才是分维度的详细数据。报告读者分两类，决策者关心选哪个、有什么风险，执行者关心哪个维度弱、怎么改。同一份报告里我会把这两层信息分开写，各取所需。
模型选型不是评测报告出来就自动完成的事。我现在的流程是评测结果先过技术评审，把明显不合格的候选淘汰掉，剩下的进业务验证环节，用小流量灰度跑真实场景，把线上指标和评测分数对照看。评测分数高但灰度表现差的模型我遇到过不止一次，原因往往是测试集没覆盖到某个线上高频场景。这类偏差反过来又能指导测试集的补充，形成正向循环。选型决策我会留一份记录，写清楚当时为什么选它、放弃了哪些候选、依据是什么，半年后回头看这份记录，能避免很多重复踩坑。
迭代优化闭环的关键是把评测嵌进研发节奏里。我的做法是模型每次有实质更新就触发一轮核心评测，结果自动跟上一版对比，退步超过阈值的维度标红预警。新版本上线前必须通过评测基线，没通过的要写清楚原因和补救计划。这套机制跑起来之后，模型迭代的试错成本明显下降，以前靠拍脑袋判断“新版本应该更好”，现在有数据兜底，团队讨论问题的语言也从“感觉”变成了“哪个维度掉了几个点”。
闭环里还有一环容易被忽略：评测结论要能反哺训练和数据侧。哪个场景分数低，对应的训练数据可能就有缺口；哪类badcase反复出现，说明数据清洗或标注规范有问题。我现在会定期把评测的短板分析同步给数据和算法同学，评测不只是裁判，还应该当侦察兵用。
4.4 持续评测机制与未来趋势：动态基准、多模态与场景化评测
持续评测这件事，我建议一开始就按“能自动跑”来设计。手动触发一次全量评测，人力成本高不说，还容易被各种排期挤掉。我现在把核心评测挂在模型构建流水线后面，模型产物一出来自动拉起评测，跑完自动写入结果库并生成对比报告。全量评测频率控制在每周一次，轻量级的冒烟评测每次构建都跑，覆盖最关键的十几个任务，几分钟出结果。这样既能保证反馈速度，又不会把资源耗光。
动态基准是我最近比较关注的方向。静态测试集用久了，模型可能“记住”了题型，分数虚高。动态基准的思路是定期用新生成的题目刷新测试集，让评测始终面向没见过的输入。我现在在尝试用线上新badcase加自动出题结合的方式更新测试集，人工审核后入库，保证新鲜度和质量兼顾。多模态评测也是个绕不开的趋势，图文、音视频任务越来越多，评测维度要从文本指标扩展到跨模态一致性和视觉质量，这块的工具和指标都还在快速演进，我目前的策略是先把文本评测体系跑稳，多模态按场景逐个接入。
场景化评测我越来越看重。通用能力分再高，落到具体业务场景里水土不服的模型太多了。我的做法是按业务线建场景评测包，每个包里有针对该场景的测试集、专属指标和权重配置，选型的时候场景包的成绩优先级高于通用榜。未来评测体系大概率会往“场景即评测单元”的方向走，模型能力评估和业务价值评估会越绑越紧。我现在的投入重点也在这儿，把场景评测包做厚做实，比追新工具新框架更解决实际问题。
最后说个心态上的体会。评测体系不是一次建成就完事的工程，它更像一个需要持续养的产品。数据要养、指标要调、流程要磨，每季度回头审视一遍哪里失效了就补哪里。我见过不少团队评测搭得很漂亮，用了半年就荒废了，根因往往是没把它嵌进日常研发流程里。让评测成为发布环节的一个默认步骤，持续转动就不再依赖谁的自觉。
